advertisement

Weblog:   MS DRM is pure smoke
Subject:   re-encode == LOSS of quality
Date:   2003-07-15 11:12:23
From:   anonymous2
there is a quality loss, you will always be able to re-encode DRM protected music, but there is a loss.


cracking the DRM would be getting to the encoded code out of the "encryption", without a re-encode.


there a numerous ways to re-encode a AAC file purchased from the iTunes Music Store.

Full Threads Oldest First

Showing messages 1 through 9 of 9.

  • Lucas Gonze photo re-encode == LOSS of quality
    2003-07-15 12:47:31  Lucas Gonze | O'Reilly Author [Reply | View]

    depends on how the re-encode works. Putting a microphone up to the speaker is one thing, picking up bits direct from the original is another. Can't say I know enough about this yet to say which one it is, but I'm inclined to believe it's direct bits because it happens within WM9, so there's no analog conversion.
    • re-encode == LOSS of quality
      2003-07-15 13:46:41  anonymous2 [Reply | View]

      If you use a lossy encoding there is a loss of quality every time you re-encode (in theory I think this need not be true in some cases, but in practice it is).

      Take any JPG picture you have, save it as a non-JPG format, reload it, and save it as a JPG again. Then compair the two images pixel for pixel. They will no longer be identical. The new one will in fact be worse. Even if you used the same quality level. (this doesn't apply to "lossless JPG"...but nobody uses that)

      The effect is worse if you use compresison methods that make diffrent asumptions about what things can be lost without noticing (converting a MP3 to a WAV and back 10 times will do less damage then converting the MP3 to an OGG and back 5 times...not because OGG is worse then MP3's, but because it makes a diffrent set of choices about which set of frequencies mask alterations in other sets of frequencies and other similar things).

      If the "re-encode" is to a lossless form though, then the re-encode doesn't hurt things. If the "re-encode" isn't really a re-encode, but some sort of clever minuplation of the bit stream it can also be harmless (for example JPG was designed so that you could rotate it 90 degreese without rencoding it...and that you can rencode a 8x8 (or 16x16?) block without altering the rest of the image)...but those are special cases. It is possiable that the "remove DRM" trick also doesn't re-encode the bit stream but strips of a DRM header, or even strips said header and unencrypts the bits, but it doesn't seem all that likely.
      • re-encode == LOSS of quality
        2003-07-22 12:15:10  anonymous2 [Reply | View]

        Similarly to how JPG has "lossless re-encode," there isn't really any good reason that you couldn't reencode an MP3 or MPEG-4 video. The point is that the original encode suffers loss, but in doing so puts the image in an easily-compressible form (by blocking it and removing high-frequency noise, etc.). After decoding it's still in this form, and so if you were to compress using the same parameters, you should get essentially the same file out.
        (This gets less and less likely the more complicated the input format is, but I think at least it would work for MP3.)

        - Tom 7
      • Lucas Gonze photo re-encode == LOSS of quality
        2003-07-15 16:10:16  Lucas Gonze | O'Reilly Author [Reply | View]

        There are two reasons to believe this isn't a lossy re-encoding. One, the way that WM9 works is that your code is inserted into a set of filters, and you have access to just about anything given that you insert yourself in the right spot. (That's based on limited understanding -- I'm a newbie with WM9 development). Two, WM9 DRM hackers are taking this seriously. So the most likely situation is that you can get access to highest-resolution bits available.

        On the other hand, I'm having a hard time finding details of the crack. The WM9 folks have decided I'm a script kiddie, and the AVSForums search is not the greatest, so I'm stuck crawling AVSForums manually.
        • re-encode == LOSS of quality
          2003-07-22 09:58:55  anonymous2 [Reply | View]

          The tool being used is GraphEdit, a part of Microsoft's SDK for DirectShow.

          It show's the underlying encoders/decoders/stream splitters used to get from a file to an output device such as a soundcard, your monitor, or (and this is the 'crack' bit) another encoder's input and a subsequent file.

          It generally is lossy, because you are reencoding the decoded stream = generational loss.

          But it's possible that the bits could be caught before decoding, and shunted into a custom-written filter that instead of decoding the bitstream, just writes it to a file after decryption.
          • re-encode == LOSS of quality
            2003-07-22 14:33:06  anonymous2 [Reply | View]

            Does this apply equally to video, or to audio only?
          • Pathetic
            2003-07-22 13:58:12  anonymous2 [Reply | View]

            Try connecting the Line Out of your soundcard back to the Line In of the same PC... poof, no DRM!

            You're just doing exactly the same thing in software... next time try catching the stream before it hits the audio renderer and we'll have something to talk about.
          • Lucas Gonze photo re-encode == LOSS of quality
            2003-07-22 10:07:11  Lucas Gonze | O'Reilly Author [Reply | View]

            Anonymous, you are the rockest man alive. Huge props to you.
            • re-encode == LOSS of quality
              2005-04-11 04:54:22  ccnz2 [Reply | View]

              im trying to use graphedit with a .wmv file....
              basically even though i have it saved on my hard drive whenever it opens in media player it acquires the licence everytime i play it.
              I downloaded it from a sports site that shows games footage and think it is rubbish that you cant open it or save it without it doing this.
              Its sports clips not a damn feature film DVD!! this licensing media is a joke...i thought my subscription paid for my rights to the file but obviously not.anyone know of a easy way round this?

Showing messages 1 through 9 of 9.