In CG journalism "proprietary" traditionally means "home-brewed", as opposed to "secret." Proprietary code is custom-written but not necessarily secret. This is just a slightly different word usage from the software development press.
Do you see my point about buffer overflows though? It doesn't matter how secure the hardware is. At some point, there will always be a piece of software with "trusted" access to the unencrypted data. And that software will be vulnerable to traditional attacks that can let you inject code of your choosing, which will execute at its "trusted" privilege level.
You would be right if *all* "trusted" software moved into micro-code in the hardware, like a stand-alone DVD player, but I don't think that is what MS has in mind for Palladium. They will almost certainly have to offer an API for third parties to write "trusted" software - they are a platform vendor, and I'm pretty sure they see Palladium as an extensible platform rather than a one-off hack for Windows Media Player.
You might also argue that MS will mandate garbage collection, bounds checking, non-executable stacks, or other techniques for reducing exploits. But even with those in place, I still wouldn't bet you a cent that the software would be impervious to attack.
This wonderful example shows how even hardware-enforced media protection schemes aren't going to work, as long as there are any vulnerabilities in the "trusted" software.
e.g. say you have a DVD player program that is "trusted" and prevents you from taking a screenshot or recording anything from a DVD. If you can find a buffer overflow or any other kind of exploit in the program, you can just have it execute your own code (rip the whole DVD) at its super-trusted privilege level.
Given that MS has a hard time keeping its HTTP server secure, I don't think buffer overflows will be too hard to find in typical razzle-dazzle media player programs:)
While CPU power is moving ahead, it always feels like internet bandwidth is lagging behind (anyone else's ISP lowered their up/down caps recently?). A good use for those extra cycles might be advanced compression algorithms to squeeze every last bit of efficiency out of our limited-bandwidth internet connections.
Consider that the Linux kernel mirrors just deprecated gzip in favor of bzip2, which provides significantly better compression, at the cost of more CPU power to encode and decode.
Or better video compression algorithms - one of the main reasons newer video codecs (MPEG-4/WMV9) compress better than early codecs (Cinepak/Indeo/MPEG-1) is that they can assume a much more powerful CPU for decoding.
Or even still image compression - JPEG-style DCT algorithms are handily outclassed by many newer wavelet algorithms. Imagine how much bandwidth you could save by replacing all your JPEGs on the web with much smaller wavelet files.
Actually it might not be necessary to overhaul every SMTP/POP3 client. You could invent a new email system (encrypted, authenticated, whatever) that accepts incoming messages via SMTP and delivers mail via POP3. I'm thinking of a secure "bridge" between the initial SMTP server and the destination POP3 server. Sort of like a VPN, but for email rather than IP packets. This way existing clients could use the system with little or no modification.
The receiving side would probably be the easiest - the destination server that receives email for you (probably at your ISP) would have to be provided with a private key to decrypt your incoming email. This could be done automatically by your ISP. Naive users and their email clients would just see the unencrypted messages via POP3.
The outbound side might require modifications to insert special headers in the SMTP message to authenticate yourself to the system (e.g. you could send a digital signature, which the SMTP server would verify against your stored private key).
This system wouldn't be as secure as end-to-end encryption (anyone with access to your mail server could subvert the private keys), but it would be a heck of a lot better than what we do today, and virtually 100% backwards-compatible with existing mail clients.
A web interface might be another good way to deliver the next generation of email. Yahoo or MSN could incorporate encryption and authentication without changing anything in their existing web interfaces.
I'd be happy with a remote protocol that functioned like VNC - i.e. just send the window contents as a (compressed) bitmap. This should be easy to implement, and performace should be acceptable for non-graphics-intensive things. (I bet 99% of people who use X remotely only need it for xterm and perhaps Emacs; nobody wants to run Photoshop or Maya remotely because the network latency will make those suck no matter how good your protocol is).
AFAIK Mac OSX implements resizing similar to the way you've described it. The only bottleneck is re-allocating the window buffer (OSX buffers all window contents on the graphics card), event delivery latency is negligible and 2D drawing is mostly negligle... On a fast Mac you can resize windows *almost* as fast as the monitor refresh, and it looks incredibly smooth because the entire window is always double-buffered. It *never* flickers.
I think the move up to HD DVD will actually be trivial. All you need is a new physical disk with about 3x the capacity. Then you just put an HD MPEG-2 stream on the disk instead of an SD stream, and keep everything else in the DVD format the same as before. This would preserve everyone's investments in authoring and encoding systems, so I think it's the logical choice. There won't be any big upheaval.
I'm pretty sure this boils down to the basic physics: to fly N times faster you need the engines to push with N^2 times as much force (AFAIK air resistance goes roughly as speed^2). Therefore, it will always be cheaper (in terms of propulsion) to fly slower, and considering pilot/crew labor it's probably always cheaper to fly one large plane than two half-size planes.
I believe that the trend on most air routes towards monstrous, slow-flying planes is an inevitable consequence of kerosene-burning propulsion and the requirement for highly skilled pilots. Airlines are simply climbing the efficiency curve toward its local maximum.
I predict that we won't see a dramatic shift in the most efficient form of air travel until we have 1) a propulsion system that doesn't burn gas, and 2) autopilots good enough to eliminate the need for a skilled human pilot. I would *love* to see everyone zipping around at supersonic speeds in car-sized, automatically-piloted aircraft (this would solve the whole airport congestion and aviation security problems as well), but I don't think that will happen until conditions 1) and 2) are met.
The only complaint I have against HP printers is that their plastic parts are very flimsy and sometimes fit together poorly. All the HP inkjet and laser printers I've used look and feel like fragile plastic kid's toys.
I have to commend HP for adding web and telnet interfaces to their ethernet-capable printers. It's nice to be able to log in and change settings that way. (However I have noticed that their DHCP client sometimes has problems re-acquiring an IP address after the server goes down, and the web interface requires Java)
HP also deserves kudos for continuing to support the old LPD protocol, and PostScript, even in this WinPrinter-dominated world. Getting one of their PostScript printers to work on Linux is a no-brainer, compared to most other kinds of printers...
You don't really need a trained compressionist, you just need a high enough bitrate. e.g. MPEG-1 at less than 1 Mbit/sec tends to look like crap (without extensive tweaking), but over 1.2Mbit/sec it's hard to screw up. I haven't worked with MPEG-2 as much but I'd guess the dividing line for NTSC video is around 5-6 Mbit/sec.
What you need the compressionist for, aside from getting every last bit of image quality from the encoder, is monitoring things like buffer-fill rate and all the other encoder parameters that need to be "just right" to meet the DVD spec.
Windows DRM *does* affect the soundcard. Windows will not play a DRM file unless you are running "certified" sound drivers. These "certified" drivers are required to disable all digital outputs while a DRM file is being played. This is called "Secure Audio Path" and it's already in Windows XP / Windows Media 9.
You can use a CD player to dub as long as it's got some kind of digital output. Analog will always work too, but that mucks with the signal quality.
The saving grace for Linux is that these audio CDs must still contain the real uncompressed tracks (even if they're hidden). You can find and rip them with enough cooperation from the CD drive and OS drivers. (see the paper by Halderman at Princeton for details)
Most of these copy-prevention schemes prevent the CD from working in PC CD-ROM drives *period*. Or, they include a corrupted table of contents that refers the PC to DRM files in a separate part of the disk, hiding the regular digital audio tracks*.
Windows DRM disables the digital output on your sound card, so only analog dubbing is possible.
You may be able to make a digital dub if you have a high-end standalone CD player with a digital output running to the PC.
* that said, the excellent 'cdparanoia' ripping software is often able to find and rip the real tracks.
The biggest problem with video modes on Windows is that DirectX offers no way to change the refresh rate from the default of 60Hz. So unless you take extra measures (like installing a "refresh rate locker" program), most games that set a video mode end up running at 60HZ even if your monitor is capable of much more.
BTW, XFree really should give more help for figuring out Modelines. When you pick a resolution and refresh rate in Windows, it's the same as adding a Modeline in XFree, but the other parameters (video start/stop/blanking) are calculated automatically. Whereas on XFree you have to figure them out yourself... I'd be much happier if XFree had some default way of choosing Modelines so that you could just say "1280x960 at 100HZ" and XFree would figure out the rest for you. There is really no point in offering the extra parameters with today's multisync monitors.
The problem is that most users need to satisfy a checklist of requirements for their mail software, and not all mail software has all the features people need. e.g. some people demand POP3 support, or local mbox support, or local maildir support, or IMAP support, or SSL, or Unicode, etc. Most mail software satisfies some but few or none satisfy all of these requirements.
Myself, I want IMAP, Unicode, in-line URL and image viewers, and hopefully maildir. I can't use the majority of mail software because it doesn't support IMAP or Unicode well. Mozilla mail does almost all I need, but its IMAP interface is lacking (it feels a lot slower than Outlook Express for some reason).
There is no way for software to query the nominal clock speed of the chip. A real 1.4GHz chip and a 1.2GHz chip running at 1.4GHz look exactly the same to the OS. Remember, CPUs of all different speeds roll off the same assembly line - it's only after testing that MHz ratings are assigned.
(I suppose the manufacturer could perform some kind of irreversable alteration to the chip when the clock speed is assigned, but AFAIK nobody does that yet)
glibc changes and also C++ ABI changes. I think Redhat 9 will include glibc 2.3 and GCC 3.2.something, which SHOULD finally establish a stable platform going forward. (for C++ at least - you can bet that software compiled against future glibc versions will not run on 2.3 - the glibc developers don't really care about backwards compatibility)
Yes, the Linux "platform ABI", i.e. syscall numbers and kernel struct definitions, has been stable for years (except for the C++ ABI on x86, which just stabilized with the release of GCC 3.2 - we hope). But, library incompatibility is an ongoing problem.
The source of most library problems, especially on distros other than Debian, is libraries that make backwards-incompatible changes without changing their major release name or number.
e.g. say libfoo-1.0 has been out for a while, and lots of packages use it. A new package comes out that requires libfoo-1.1, so you upgrade libfoo. But, libfoo-1.1 isn't quite backwards-compatible with all the other binaries that were linked against -1.0. Maybe 1.1 was compiled with GCC 3.2, or linked against a different version of libstdc++, or with incompatible CFLAGS, or maybe 1.1 omits or alters the behavior of an old entry point. So, while the new package that expects libfoo-1.1 works fine, the rest of your system suddenly breaks. The only ways out are to downgrade libfoo, or recompile every program that uses libfoo. Both alternatives are unacceptable for production users, although Linux k1ddiez with nothing else to do with their time don't seem to mind recompiling.
(Windows developers will recognize this as a sinister variant of "DLL hell")
The way you avoid this mess is by changing the name or major version number of a library any time the SLIGHTEST backwards-incompatible change is made. So libfoo-1.0 can remain installed side-by-side with the new libfoo-2.0 or libfoo2-1.0. Debian does this, but most other distro makers don't take enough care to watch for incompatible changes. Linux ".SO hell" is the result...
Redhat is just too casual about backwards compatibility. Sooo many RPM updates break packages that depended on the old version. (if it weren't for Debian I'd probably have gone mad long ago because of this...)
Low- and mid-range CRTs aren't usually capable of resolving pixels at their maximum rated resolution, whereas LCDs by definition always draw perfect pixels at their nominal resolution. (even my top-of-the-line 21" Sony CRT works great at 1280x1024 but the pixels go to fuzz at 1600x1200).
From a signal-processing standpoint, it might actually be preferable to have pixels drawn as overlapping blobs rather than perfect squares, but squares will always look sharper to most viewers than blobs.
When filmed content is broadcast in HD, does the MPEG stream actually take advantage of the "repeat field" flags to encode only 24 frames per second, like DVDs do? Or are the extra fields simply "burned in" to a regular 60 field per second MPEG stream?
One complication with these "inverse telecine" systems is that the field ordering might not be consistent between cuts. It will be consistent for a movie that is edited at 24fps and then telecine'd all at once, but lots of things are now shot on film, telecine'd shot-by-shot (with 3:2 pulldown), and THEN edited in a 60 field environment. So any cut is liable to break the 3:2 field ordering. (the video editors I have spoken to about this problem seem not to care, if they even understand the issue at all...)
I certainly feel this effect - I wish I could make it easier for people to respond to me via email without inviting more spam. The best (imcomplete) solutions I've found are to print my email address as a little in-line GIF (which works until someone tries to click on it), or to store the address in obfuscated form and use JavaScript to de-obfuscate it at display time (which assumes a working JavaScript browser).
I just realized something - there IS a common DRM format that lets you encrypt your own stuff - Microsoft's! Ironically, everything they've been saying about DRM as a "security" feature implies that you'll be able to encrypt your own content. This is NOT true for any of the "ivory tower" DRM schemes (CSS, DTCP, SDMI, etc). What irony, MS may be the enabler for independent artists to take advantage of DRM...
The Linux IEEE-1394 driver set now includes a driver for playing audio through firewire (amdtp, by Kristian Høgsberg). We are currently working on full robust support for the IEC 61883 protocol suite (of which the audio protocol is a member).
amdtp handles cleartext only though, it won't transmit or receive DTCP/scrambled streams.
The main thing they're trying to prevent is a home user making a copy-proof disc of their OWN original music. Ever notice how none of the common DRM formats let you encrypt stuff you've made yourself? The industry wants to make sure that all up-and-coming talent has to come through their doors...
Slashdot Mirror
In CG journalism "proprietary" traditionally means "home-brewed", as opposed to "secret." Proprietary code is custom-written but not necessarily secret. This is just a slightly different word usage from the software development press.
I got my $20 Microsoft Mouse rebate on time (3-4 weeks), and they didn't ask for much personal info.
Do you see my point about buffer overflows though? It doesn't matter how secure the hardware is. At some point, there will always be a piece of software with "trusted" access to the unencrypted data. And that software will be vulnerable to traditional attacks that can let you inject code of your choosing, which will execute at its "trusted" privilege level.
You would be right if *all* "trusted" software moved into micro-code in the hardware, like a stand-alone DVD player, but I don't think that is what MS has in mind for Palladium. They will almost certainly have to offer an API for third parties to write "trusted" software - they are a platform vendor, and I'm pretty sure they see Palladium as an extensible platform rather than a one-off hack for Windows Media Player.
You might also argue that MS will mandate garbage collection, bounds checking, non-executable stacks, or other techniques for reducing exploits. But even with those in place, I still wouldn't bet you a cent that the software would be impervious to attack.
This wonderful example shows how even hardware-enforced media protection schemes aren't going to work, as long as there are any vulnerabilities in the "trusted" software.
:)
e.g. say you have a DVD player program that is "trusted" and prevents you from taking a screenshot or recording anything from a DVD. If you can find a buffer overflow or any other kind of exploit in the program, you can just have it execute your own code (rip the whole DVD) at its super-trusted privilege level.
Given that MS has a hard time keeping its HTTP server secure, I don't think buffer overflows will be too hard to find in typical razzle-dazzle media player programs
While CPU power is moving ahead, it always feels like internet bandwidth is lagging behind (anyone else's ISP lowered their up/down caps recently?). A good use for those extra cycles might be advanced compression algorithms to squeeze every last bit of efficiency out of our limited-bandwidth internet connections.
Consider that the Linux kernel mirrors just deprecated gzip in favor of bzip2, which provides significantly better compression, at the cost of more CPU power to encode and decode.
Or better video compression algorithms - one of the main reasons newer video codecs (MPEG-4/WMV9) compress better than early codecs (Cinepak/Indeo/MPEG-1) is that they can assume a much more powerful CPU for decoding.
Or even still image compression - JPEG-style DCT algorithms are handily outclassed by many newer wavelet algorithms. Imagine how much bandwidth you could save by replacing all your JPEGs on the web with much smaller wavelet files.
Actually it might not be necessary to overhaul every SMTP/POP3 client. You could invent a new email system (encrypted, authenticated, whatever) that accepts incoming messages via SMTP and delivers mail via POP3. I'm thinking of a secure "bridge" between the initial SMTP server and the destination POP3 server. Sort of like a VPN, but for email rather than IP packets. This way existing clients could use the system with little or no modification.
The receiving side would probably be the easiest - the destination server that receives email for you (probably at your ISP) would have to be provided with a private key to decrypt your incoming email. This could be done automatically by your ISP. Naive users and their email clients would just see the unencrypted messages via POP3.
The outbound side might require modifications to insert special headers in the SMTP message to authenticate yourself to the system (e.g. you could send a digital signature, which the SMTP server would verify against your stored private key).
This system wouldn't be as secure as end-to-end encryption (anyone with access to your mail server could subvert the private keys), but it would be a heck of a lot better than what we do today, and virtually 100% backwards-compatible with existing mail clients.
A web interface might be another good way to deliver the next generation of email. Yahoo or MSN could incorporate encryption and authentication without changing anything in their existing web interfaces.
I'd be happy with a remote protocol that functioned like VNC - i.e. just send the window contents as a (compressed) bitmap. This should be easy to implement, and performace should be acceptable for non-graphics-intensive things. (I bet 99% of people who use X remotely only need it for xterm and perhaps Emacs; nobody wants to run Photoshop or Maya remotely because the network latency will make those suck no matter how good your protocol is).
AFAIK Mac OSX implements resizing similar to the way you've described it. The only bottleneck is re-allocating the window buffer (OSX buffers all window contents on the graphics card), event delivery latency is negligible and 2D drawing is mostly negligle... On a fast Mac you can resize windows *almost* as fast as the monitor refresh, and it looks incredibly smooth because the entire window is always double-buffered. It *never* flickers.
I think the move up to HD DVD will actually be trivial. All you need is a new physical disk with about 3x the capacity. Then you just put an HD MPEG-2 stream on the disk instead of an SD stream, and keep everything else in the DVD format the same as before. This would preserve everyone's investments in authoring and encoding systems, so I think it's the logical choice. There won't be any big upheaval.
I'm pretty sure this boils down to the basic physics: to fly N times faster you need the engines to push with N^2 times as much force (AFAIK air resistance goes roughly as speed^2). Therefore, it will always be cheaper (in terms of propulsion) to fly slower, and considering pilot/crew labor it's probably always cheaper to fly one large plane than two half-size planes.
I believe that the trend on most air routes towards monstrous, slow-flying planes is an inevitable consequence of kerosene-burning propulsion and the requirement for highly skilled pilots. Airlines are simply climbing the efficiency curve toward its local maximum.
I predict that we won't see a dramatic shift in the most efficient form of air travel until we have 1) a propulsion system that doesn't burn gas, and 2) autopilots good enough to eliminate the need for a skilled human pilot. I would *love* to see everyone zipping around at supersonic speeds in car-sized, automatically-piloted aircraft (this would solve the whole airport congestion and aviation security problems as well), but I don't think that will happen until conditions 1) and 2) are met.
The only complaint I have against HP printers is that their plastic parts are very flimsy and sometimes fit together poorly. All the HP inkjet and laser printers I've used look and feel like fragile plastic kid's toys.
I have to commend HP for adding web and telnet interfaces to their ethernet-capable printers. It's nice to be able to log in and change settings that way. (However I have noticed that their DHCP client sometimes has problems re-acquiring an IP address after the server goes down, and the web interface requires Java)
HP also deserves kudos for continuing to support the old LPD protocol, and PostScript, even in this WinPrinter-dominated world. Getting one of their PostScript printers to work on Linux is a no-brainer, compared to most other kinds of printers...
You don't really need a trained compressionist, you just need a high enough bitrate. e.g. MPEG-1 at less than 1 Mbit/sec tends to look like crap (without extensive tweaking), but over 1.2Mbit/sec it's hard to screw up. I haven't worked with MPEG-2 as much but I'd guess the dividing line for NTSC video is around 5-6 Mbit/sec.
What you need the compressionist for, aside from getting every last bit of image quality from the encoder, is monitoring things like buffer-fill rate and all the other encoder parameters that need to be "just right" to meet the DVD spec.
Windows DRM *does* affect the soundcard. Windows will not play a DRM file unless you are running "certified" sound drivers. These "certified" drivers are required to disable all digital outputs while a DRM file is being played. This is called "Secure Audio Path" and it's already in Windows XP / Windows Media 9.
You can use a CD player to dub as long as it's got some kind of digital output. Analog will always work too, but that mucks with the signal quality.
The saving grace for Linux is that these audio CDs must still contain the real uncompressed tracks (even if they're hidden). You can find and rip them with enough cooperation from the CD drive and OS drivers. (see the paper by Halderman at Princeton for details)
Most of these copy-prevention schemes prevent the CD from working in PC CD-ROM drives *period*. Or, they include a corrupted table of contents that refers the PC to DRM files in a separate part of the disk, hiding the regular digital audio tracks*.
Windows DRM disables the digital output on your sound card, so only analog dubbing is possible.
You may be able to make a digital dub if you have a high-end standalone CD player with a digital output running to the PC.
* that said, the excellent 'cdparanoia' ripping software is often able to find and rip the real tracks.
The biggest problem with video modes on Windows is that DirectX offers no way to change the refresh rate from the default of 60Hz. So unless you take extra measures (like installing a "refresh rate locker" program), most games that set a video mode end up running at 60HZ even if your monitor is capable of much more.
BTW, XFree really should give more help for figuring out Modelines. When you pick a resolution and refresh rate in Windows, it's the same as adding a Modeline in XFree, but the other parameters (video start/stop/blanking) are calculated automatically. Whereas on XFree you have to figure them out yourself... I'd be much happier if XFree had some default way of choosing Modelines so that you could just say "1280x960 at 100HZ" and XFree would figure out the rest for you. There is really no point in offering the extra parameters with today's multisync monitors.
The problem is that most users need to satisfy a checklist of requirements for their mail software, and not all mail software has all the features people need. e.g. some people demand POP3 support, or local mbox support, or local maildir support, or IMAP support, or SSL, or Unicode, etc. Most mail software satisfies some but few or none satisfy all of these requirements.
Myself, I want IMAP, Unicode, in-line URL and image viewers, and hopefully maildir. I can't use the majority of mail software because it doesn't support IMAP or Unicode well. Mozilla mail does almost all I need, but its IMAP interface is lacking (it feels a lot slower than Outlook Express for some reason).
There is no way for software to query the nominal clock speed of the chip. A real 1.4GHz chip and a 1.2GHz chip running at 1.4GHz look exactly the same to the OS. Remember, CPUs of all different speeds roll off the same assembly line - it's only after testing that MHz ratings are assigned.
(I suppose the manufacturer could perform some kind of irreversable alteration to the chip when the clock speed is assigned, but AFAIK nobody does that yet)
glibc changes and also C++ ABI changes. I think Redhat 9 will include glibc 2.3 and GCC 3.2.something, which SHOULD finally establish a stable platform going forward. (for C++ at least - you can bet that software compiled against future glibc versions will not run on 2.3 - the glibc developers don't really care about backwards compatibility)
Yes, the Linux "platform ABI", i.e. syscall numbers and kernel struct definitions, has been stable for years (except for the C++ ABI on x86, which just stabilized with the release of GCC 3.2 - we hope). But, library incompatibility is an ongoing problem.
The source of most library problems, especially on distros other than Debian, is libraries that make backwards-incompatible changes without changing their major release name or number.
e.g. say libfoo-1.0 has been out for a while, and lots of packages use it. A new package comes out that requires libfoo-1.1, so you upgrade libfoo. But, libfoo-1.1 isn't quite backwards-compatible with all the other binaries that were linked against -1.0. Maybe 1.1 was compiled with GCC 3.2, or linked against a different version of libstdc++, or with incompatible CFLAGS, or maybe 1.1 omits or alters the behavior of an old entry point. So, while the new package that expects libfoo-1.1 works fine, the rest of your system suddenly breaks. The only ways out are to downgrade libfoo, or recompile every program that uses libfoo. Both alternatives are unacceptable for production users, although Linux k1ddiez with nothing else to do with their time don't seem to mind recompiling.
(Windows developers will recognize this as a sinister variant of "DLL hell")
The way you avoid this mess is by changing the name or major version number of a library any time the SLIGHTEST backwards-incompatible change is made. So libfoo-1.0 can remain installed side-by-side with the new libfoo-2.0 or libfoo2-1.0. Debian does this, but most other distro makers don't take enough care to watch for incompatible changes. Linux ".SO hell" is the result...
Redhat is just too casual about backwards compatibility. Sooo many RPM updates break packages that depended on the old version. (if it weren't for Debian I'd probably have gone mad long ago because of this...)
Low- and mid-range CRTs aren't usually capable of resolving pixels at their maximum rated resolution, whereas LCDs by definition always draw perfect pixels at their nominal resolution. (even my top-of-the-line 21" Sony CRT works great at 1280x1024 but the pixels go to fuzz at 1600x1200).
From a signal-processing standpoint, it might actually be preferable to have pixels drawn as overlapping blobs rather than perfect squares, but squares will always look sharper to most viewers than blobs.
When filmed content is broadcast in HD, does the MPEG stream actually take advantage of the "repeat field" flags to encode only 24 frames per second, like DVDs do? Or are the extra fields simply "burned in" to a regular 60 field per second MPEG stream?
One complication with these "inverse telecine" systems is that the field ordering might not be consistent between cuts. It will be consistent for a movie that is edited at 24fps and then telecine'd all at once, but lots of things are now shot on film, telecine'd shot-by-shot (with 3:2 pulldown), and THEN edited in a 60 field environment. So any cut is liable to break the 3:2 field ordering. (the video editors I have spoken to about this problem seem not to care, if they even understand the issue at all...)
I certainly feel this effect - I wish I could make it easier for people to respond to me via email without inviting more spam. The best (imcomplete) solutions I've found are to print my email address as a little in-line GIF (which works until someone tries to click on it), or to store the address in obfuscated form and use JavaScript to de-obfuscate it at display time (which assumes a working JavaScript browser).
I just realized something - there IS a common DRM format that lets you encrypt your own stuff - Microsoft's! Ironically, everything they've been saying about DRM as a "security" feature implies that you'll be able to encrypt your own content. This is NOT true for any of the "ivory tower" DRM schemes (CSS, DTCP, SDMI, etc). What irony, MS may be the enabler for independent artists to take advantage of DRM...
The Linux IEEE-1394 driver set now includes a driver for playing audio through firewire (amdtp, by Kristian Høgsberg). We are currently working on full robust support for the IEC 61883 protocol suite (of which the audio protocol is a member).
amdtp handles cleartext only though, it won't transmit or receive DTCP/scrambled streams.
The main thing they're trying to prevent is a home user making a copy-proof disc of their OWN original music. Ever notice how none of the common DRM formats let you encrypt stuff you've made yourself? The industry wants to make sure that all up-and-coming talent has to come through their doors...