I have a cheap knock-off of the very box you pointed to.

It works fine as a DVR but as far as I can tell, it's just recording one of the programs not the entire stream. Also, there is no indication of whether it is recording meta-data and other data or if it's discarding it before recording it. In other words, it's not what I am looking for.

In original uncompressed actual HD, I could do that too. Now it has all been compressed to where I can't anymore.

Anyone know of a sub-$1000 device that will record and play back "raw" ATSC signals?

In short,

* a recording device that will take an arbitrary digital TV channel, convert it from analog to digital (all airwaves are inherently analog at some level), and record the bits verbatim, along with some meta-data like the time of day, the frequency recorded, and maybe some extracted data like the digital sub-channels in the stream and information about what is playing on each sub-channel now and in the near future.

* ideally, DVR-like timer recording capability.

* a playback device that will put that recording onto a specific RF frequency. If the RF frequency is the same as the originally recorded frequency, my television should be fooled into thinking it is a channel that the TV already has mapped (e.g. RF channel 14, "display" as channel 20).

* ideally, a DVR-playback capability that would make the box act like a DVR, albeit one that uses a lot more disk space than your typical DVR. The output would go to the TV over a dedicated AV connection not the RF "CATV/Antenna" connection.

* ideally, the ability to recognize a USB device and copy the raw recording to it for storage or analysis/playback on a computer that can read the format.

Q: The use of such a device for legal and engineering purposes is obvious, but why would any normal consumer want such a thing?

A: Because at least then I'll KNOW for sure that I recorded what my receiver (or more specifically, the receiver in this magic box) received, not some partially-processed intermediate version. It will also allow me to record content encoded in formats that haven't been developed yet (as of January 2015), so I can play them back on a TV that supports that format.

I want large-data formats to succeed because I want my "boxed sets" to take up less shelf space. Give me an entire season at as-broadcast resolution on a single disk (13 episodes of HD or 3-4 times that for a very-good-quality digitization of old stuff that only exists on broadcast-quality NTSC tapes would be nice), including bonus material, and I'll be happier than if the large disks are used only for higher-definition content. My eyes aren't what they once were and neither are my ears.

For the same reason I wish all CD players (especially those in cars) were replaced with "audio disk" players that could play audio from video DVDs, DVD-audio, and all common computer audio formats in addition to the current CD-audio/MP3/WAV formats that seem common for new players today.

How about taking a Yacc-like approach and creating a meta-standard that has each "file" on the disk include a list of codecs required for that file and which has each disk include a description of the various video- and audio-decoding algorithms needed to play the "files" on the disk (excluding the common standards that existed when the "meta-standard" was finalized - those would be baked in to all players), then let the player figure out what to send to the output ports based on the data format, the data, the processing capability of the player, and if known (or presumed, for one-way "outputs" like analog) the capability of the display device.

This way the only "hardcoded" part of the standard would have to deal with the raw laser I/O from the disk to the laser pickup on the player, basic things like the layout of error-correcting code, slightly-less-basic things like the filesystem-layout or equivalent, and a standard way for the player to understand the disk and file meta-data. Then the player could take it from there, creating codecs (or more accurately, de-coders) as needed based on the information on the disks.

The same technique could be used for future-proofing display devices. For display-devices with 2-way communication, the display could communicate its capabilities to the player in a standardized format, and possibly even communicate as-yet-undefined capabilities to the player as well (UV/IR, specialized color gamuts, infra/ultrasonic capability, alarms and sensors, etc.). These capabilities could be matched up with the format of the disk.

Example:

If the disk has a codec that says "supports SENSOR_STD_2019a" and the meta-code for the standard "SENSOR_STD_2019a" says
"if SENSOR_STD_2019a data NO_WARM_BODY_PRESENT becomes TRUE then execute GO_BACK_15_SECONDS_AND_PAUSE"

and the display tells the player
"SENSOR_STD_2019a:NO_WARM_BODY_PRESENT=TRUE"
then the player can act on it, even if the player was manufactured well before SENSOR_STD_2019a even existed.

The speed hit would suck but steganographic protocols for getting things like encrypted email back and forth may be badly needed for countries like China.

http://www.seeminglyinnoculous...

might contain a bunch of images of pink ponies, which each contain stenographicly-encoded encrypted emails. If you want to send an email, you upload what appears to China's Firewall to be just another Pink Pony.

I can't be sure, but I think this may have already been done :).

While you could do a full-blown VPN with this technology, I would hate to think how long it would take to load a typical 0.1-5MB web page over such a VPN.

The same type of "deep inspection" firewall trick can and probably should be at least CONSIDERED for ANY mission-critical machine that is deemed "too risky" to put on the same network with "unacceptably high risk of becoming contagious" machines. In some cases it may even make sense to apply this technique to machines that ARE running supported OSes and which are BELIEVED to be very well protected all by themselves.

For example, if you are running an in-house web site to provide selected employees with a web interface to the corporate back-end data center, it may make sense to put a dedicated security box between the data server and the web server and another dedicated security box between the web server and the company's "office" network. This way if some employee's machine gets infected, the web server is less likely to become compromised, and if the web server is compromised it is less likely to compromise the back-end data server. Also, the security devices can watch for suspicious activity, such as out-of-the-ordinary traffic patterns from the "office" network to the web server or out-of-the-ordinary data requests from the web server to the data server and raise alarms where warranted.

I'm sure by now you are worried about "what if the security boxes get hacked." That is a concern. There are ways of making the security boxes be pass-through boxes which are invisible/non-addressable to the office network, the web server, and to the back-end data center, which would mean that the only ways to deliberately "hack" them would be through a different network connection entirely (such as the connection to a dedicated, otherwise-non-network-connected computer in your security officer's office) or by sending carefully manipulated traffic through them that was designed to "break the XYZ-brand security box that someone told you might be there" or "break the security box that your traffic-analysis pre-hack investigation made you suspect was there."

If you don't care about STOPPING bad traffic but just want to raise alarms, a traffic-splitter that feeds a copy of all traffic to your security boxes will do the job and it will be all but completely invisible to the networks they are monitoring (a splitter will not be completely invisible, but it can be made to look like a non-addressable/dumb repeater, switch or hub from the point of view of the networks it is connected to - the only hint of its existence to someone without physical access to measure voltage levels may be a very slight increase in latency).

If you have hardware firewalls that do deep-packet inspection and reject all traffic that doesn't match whitelisted traffic, AND your whitelist is detailed enough so that in practice it rejects all unwanted traffic, you should be okay.

So, unless the traffic of your specific can't-migrate-to-a-supported-OS application is too expensive to distinguish from unwanted traffic, you should be able to firewall a server so well that the fact that the OS is unsupported and otherwise vulnerable to attack is no longer a "must fix now" issue.

That doesn't mean it isn't an issue, and I would still recommend finding some way to phase it out, but it just means you won't have to fully decommission your Windows 2003 server this year or even this decade.

I'm pretty sure the first few BC's were "pre-mined" by the same person/group which invented BC in the first place, if not as a deliberate way to create BC then as a way to test the protocols, algorithms, and code.

I addressed this general terms in the original post when I said "The company that created and pre-mined the cards would be on the hook for all transaction fees."

In other words, the issuing authority would have to absorb the computational costs of adding all transactions to the blockchain for that currency. They would be "on the hook" because 1) without mining, nobody would validate transactions without imposing a fee, and 2) with transaction fees, fewer people would bother to use the crypto-currency as a "gift certificate."