Slashdot Mirror
DRM Reduces Battery Life
gr8_phk writes "An interesting article
over at C|Net claims that playing DRMed music can reduce battery life up to 25 percent. Yet another reason to stick with plain old MP3 files." From the article: "Those who belong to subscription services such as Napster or Rhapsody have it worse. Music rented from these services arrive in the WMA DRM 10 format, and it takes extra processing power to ensure that the licenses making the tracks work are still valid and match up to the device itself. Heavy DRM not only slows down an MP3 player but also sucks the very life out of them."
Until that perception is corrected, DRM is a fact of life.
So how do we correct this perception? Maybe by being responsible consumers and not "sharing" all digital media with the planet without permission. If the artist, composer or whatever releases it with "redistribute freely", then by all means, post it, share it, copy it. But, if it is released with "no redistribution allowed" then nobody shares it, copies it, etc.
If that were to start happening market forces could then (perhaps) influence the licensing of music, video and other digital media. I do not see this happening anytime soon or even in my lifetime. Therefore, DRM is a live-or-die proposition to content owners. They can either protect it or sell one copy.
I am reminded of the Chinese policy of charging the family of the executed for the price of the bullet used in the execution. In other words, something bad is done to you and you are asked to pay for the price of the administration of the badness as well as experiencing the badness itself.
The flag just makes more sense than the constitution. - Judas Gutenberg
A good summary of the CNet study is at http://www.cdfreaks.com/news/13193.
The Slashdot headline/summary is a little misleading. The test showed that Apple's FairPlay DRM caused about an 8% battery life penalty. It was the Zen Micro with the WMA DRM that caused a 25% drop in battery life. In this case, (if you HAVE to have DRM'd music), it seems Apple's scheme is the way to go.
Some people have raised the issue that they compared 192kbps WMA files with 128kbps AAC (i.e. iTMS) files. AAC, in general, sounds pretty good at 128kbps. (Geek Disclosure Time): I've run a few double-blind, multi-listener tests, and most people put 128 AAC about equal with 192 MP3 (constant bitrate). I have no idea whether 192 WMA is overkill - if that's what Napster provides, well, I'm assuming that's comparable sound quality.
I'm not an engineer, so I can't say whether or not the bitrate difference could reasonably account for that great a difference in battery drain. I will, however, note that if you choose to use a less-efficient codec, that's your fault.
AAC,WMA,Vorbis from everything i read use more CPU time to decode then a mp3 track. They also have smaller file size when it comes to the same quality. 128 AAC(or is it 160 i don't remember) itune track sounds a lot better than a 128 bit mp3.
Have you ever been to a turkish prison?
Who's to say that non-DRM WMA files are not just restricted with a known key? This actually makes sense because WMA was designed to be a digital restriction format from the start. In a post treacherous-computing world it would then be possible to identify creative-commons files versus files encoded before pervasive restrictions were in place. And it would offer the benefit of DRM files not 'costing' anything over free ones. So clearly there is motive for making non-DRM files use a known key rather than being just the raw data.
So unless you know differently then your suggestion could be *masking* the cost of DRM by doing an invalid comparison. Instead this comparison is between formats that a reasonable person might choose, a known-free format and a known-restricted one. They could have compared ogg vs wma for instance, but comparing wma to drm-wma is actually even worse than mp3 vs wma. I think it's a good comparison, definitely not worth the scorn so many have dumped on it.
Speaking of parroting, this has shown up several times in the discussion, with only assumptions and no evidence to back it up.
Take a look here: http://www.foobar2000.org/foospeed/
That's a collection of decoding speed results from various machines using foobar2000. It doesn't include WMA, but AAC and MP3 are on there, and the results are rather consistent in showing that AAC decodes faster than MP3. Not overwhelmingly, but definitely noticeable. Regardless, it disproves the whole "newer codec, therefore must be more complex, therefore must take longer to decode" assumption.
When you first open up a DRM file to play it, yes a little bit of processing occurs right then doing public/private key decryption to unlock the RC4 encryption key used to decrease the rest of the file. This however is probably about the same amount of juice as is required to play 1/10 a second of audio. During actual audio playback the players are doing an RC4 block cipher decryption operation. That's a linear time operation on par with generating a modulus for 8 bits. Meaning it's basically nothing compared to the horsepower needed to convert from compressed audio to waveform pcm audio. The article review is a crock of crap.
Putting aside for a moment that the article itself is more about battery life of various players than about the affect of DRM on battery life, the few statements made about DRM and battery life came from a very flawed test. The authors never tested un-DRMed AAC or WMA, to account for the higher processing needed to decode the more complicated file formats.
But, in the interest of science, I would like to see DRM's real affect on battery life in portable music players. Here is the test I propose:
Purchase a 128kbps AAC/Fairplay track from iTunes.
Purchase the same track as a 192kbps WMA/DRM 10 from Napster.
Rip the same track from CD, and create five versions:
- 44.1kHz wav
- 128kbps mp3
- 192kbps mp3
- 128kbps AAC (clean - no FairPlay)
- 192kbps WMA (clean - no DRM 10)
Now we have seven tracks to test, two with DRM, two identical without DRM, one as a control, and two for bitrate studies. For each track:
- set the volume on max
- turn off the backlight
- plug in a set of standard earbud headphones
- load the track on the player while the player is plugged in
- make sure the track is the only thing on the hard drive
- place the track in its own playlist and set to infinite repeat
- press play at the moment you unplug the power cord
- time how long it takes for the battery to run out
- plug the player back in and charge to full
Ideally, this test should be run several times for each track on the exact same player, in the same order every time, to correct for possible changes in the amount of charge the battery can hold. It might be interesting to run the test on many different players, as well, and see how they fare.
Does anyone at Slashdot own a player that can handle all three formats, and would be willing to conduct the tests?
For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.