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."

6 of 296 comments (clear)

  1. Misleading Headline: 8% vs 25% by GiSqOd · · Score: 5, Interesting

    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.

  2. Re:Wrong! by ad0gg · · Score: 5, Interesting

    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?

  3. Re:Argh by 0xABADC0DA · · Score: 5, Interesting

    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.

  4. Re:Argh by DeeKayWon · · Score: 4, Interesting
    It takes more power to decode WMA (DRM or not) than it does to decode MP3. Ditto for AAC.

    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.

  5. DRM Decryption uses almost no cpu by DJScrib · · Score: 5, Interesting

    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.

  6. Comparing Apples to Sonys by AeroIllini · · Score: 4, Interesting

    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.