In the following article, this technique is claimed to circumvent DRM, "...but it does cause a generational loss in audio quality."

http://arstechnica.com:80/news.ars/post/20...cumvention.html

Why would it be lossy?

Additional Note: Going from WMA to CD WAV should not cause any loss. Let's say it started life as a 192 WMA. But once it is in WAV format, if one then does a 320 CBR with LAME, is it the case that 192 WMA won't "fit" inside a 320 CBR without a whole "generation" of loss? That's hard to believe.

You know - I had composed a lengthy explanation on how this was still lossy to lossy conversion, and referenced you to previous posts on the subject, but I changed my mind.
Let's make this a learning exercise.
How is this not lossy to lossy transcoding?

You are right. It is. I understand why. Because additional transcoding is going on. I realized that my first post clearly implied that I did not understand that there would be no loss. After I posted it, but probably before you finished your response, I edited it to explain exactly what I was thinking.

Possibly answering that clarification of my question might be more educational for me and others. It might be useful to know just how much loss one could have in my example. Also, I wonder if the original WMA was of low enough bit encoding, whether one could have virtually no loss--say if the original WMA was 96 kbps and the subsequent WMA to WAV to MP3 was ending in 320 CBR.

101

Exactly 1091kbps of loss. There is no more meaningful answer than that. If you want to know what it sounds like, then I'm afraid you'll have to do it yourself and listen, because no two people have the same ears.



It's not impossible that lower bitrate originals will actually suffer more loss during the second encoding than higher bitrate ones.

The reason? A lower bitrate WMA will have more noise added, which will be losslessly recreated on the CD, making it more difficult to compress.

I've no idea if that is true in practice; I'm just illustrating that lossy compression is a more complex process in data terms than meets the eye (or ear, for that matter.)

Lossy encoders save bits not by removing portions of the audio spectrum, but rather by storing some transform coefficients with less bits of precision than others (for a simplified explanation, think in terms of decimal points, the encoder might decide to store a value of 2.8358233 as 3). Because of this, encoders typically add noise just as much as they remove sound. The second encoder (LAME 320kbps in your example) can't tell the difference between this added distortion and legitimate information in the audio, so it typically wastes a lot of bits needlessly encoding the noise.

Another major problem with lossy transcoding is differing block sizes. Due to the nature of transforms, an impulse smaller than the block size will "smear" in time to fill the block. When smeared backwards, this is called pre-echo. When you re-encode with a different block size (or even the same block size depending on the encoder delay), the impulse smears even further in time.

Thanks to all for the information.

There's also another loss involved. Burning lossy material as an audio CD results in rounding errors because a higher precision bit-depth is converted to a lower precision bit-depth. This is because lossy formats like WMA or MP3 don't have a fixed bit depth but an audio CD (which is like uncompressed WAV) is limited to a fixed bit-depth of 16 bits. So, basically you are converting 32-bit floating point values to 16-bit integer values. This is why it's never a perfect solution, even if you plan to convert the material to a lossless format like FLAC.

That would happen during playback anyway, so you aren't really losing anything by decoding MP3 to PCM.

In the majority of cases, the input was 16-bit to begin with anyway.

Well, I for example use a bit-depth of 24 bits for playback. The material is decoded as 32-bit floating point and rendered as 24-bit. And it doesn't matter if it once was 16-bit if it is now in a lossy format like WMA or MP3 because these formats do not store exact sample values. Those values are only reconstructed during the decoding process and the higher the accuracy the better. At least dithering should be applied if a conversion to 16-bit is necessary. But do you have that much control over the burning process in those DRM-supporting programs? I doubt it.

You could also use dither with noise shaping when decoding to 16bit WAVs that are going to be written on a CD

Any kind of proof that this process is worth it or is it a feel good thing?

Can't agree here - Did you ever tried to recompress jpg-s? Take highly compressed picture and do "save" it to jpg with "higest quality" again. Any difference?

Once data was suffered from lose encoding it becomes "easy target" for the next consecutive re-encoders.

Audio compression is not the same thing as image compression.

Regardless, JPG compression still suffers from compounding distortions when re-encoding. It's just that one pass through might not be noticable (just as 192kbps WMA -> 320kbps MP3 might not be noticable). But there is provable quality loss. Note that the original poster thought that the transcoding process might be completely lossless, so we aren't talking about perceptual quality loss, but rather absolute quality loss.


This is simply untrue.

JPG doesn't overlap the DCT blocks (you can see the boundaries with too much compression) - mp3 does overlap the MDCT blocks.

So JPG can "see" the same data twice, and get the same DCTs coefficient a second time around. It will normally re-quantise them slightly differently, but it doesn't have to (arithmetic accuracy limitations aside).

mp3 can never see the same MDCT coefficients the second time around - the block they came from has been overlapped in the time domain, so the audio to generate them is unrecoverable.

If there was no overlap, and you could sync to block boundaries, then you could, in theory, get the same MDCT data back and potentially keep the existing quantisation. A single sample delay would wreck this. The filterbank before the MDCT makes it impossible too. However, the necessity to overlap the blocks to avoid clicks is the basic killer!

The BBC MPEG ATLANTIC project (Google for it) and it's MPEG mole were interesting steps towards this, but not widely used.

Cheers,
David.

Thanks for explanation.

OK, let's make simple test then:

"Scorpions - Loving You Sunday Morning" Coding with LAME 3.98b6.
1. Lossless -> LAME V2: bitrate is 192 kbps
2. Lossless -> LAME V6 -> LAME V2: bitrate is 147 kbps

Any comments?

It also depends on how version 2 sounds compared to version 1. Just because the encoder *thinks* it can save bits doesn't necessarily mean it's correct, especially since you're not using best practice to encode.

Also I think it would be more interesting to look at this the other way round (i.e. going from V2 to V6, rather than V6 to V2.) - while that's still not a good idea I can understand why people would do it.

Sure, it sounds worse. I show this example to prove that encoding already encoded file is much easier job for encoder - we do not talk about how it sounds (thought I bet it sounds similar to V6). It just to show that to reach quality for V2 encode encoder *thinks* it's enough to use less bitrate for 2) than for 1)


Why it should be more interesting? For V6 compression, file compressed with V2 probably looks like uncompressed at all:
3. Lossless -> LAME V6: bitrate is 121 kbps
4. Lossless -> LAME V2 -> LAME V6: bitrate is 123 kbps

That's predominently due to the V6 encoded file having been through tighter low pass filter.



If it's not obvious why it more interesting then you are really lacking some basic understanding here. It's more interesting because that's the only way a sane person would ever do it (transcode). A sane person might well trancode V2 to V6 (in instances where the original in not readily available to them) to reduce file size for a DAP for example. It's very hard to imagine any instances where a sane person would want to transcode V6 to V2.


Your own data and it neatly disproves your very point, but yet you cling to it. Why?

In an attempt to preserve quality (read: try not to introduce more additional artifacts than are necessary in the process) after an edit to the decompressed file when V6 is the only source available.

Maybe. Even so, from when we do not count low pass filter as integral part of mp3 encoder? Especially for -Vx modes?


Did you read very first message in the thread you are answering in?


Because I personally think that for _sane_ person V2 -> V6 encoding has no sense. My statement is about lowQ coded -> HighQ coded case.

Yes. What about
3. Lossless -> LAME V6: bitrate = ?
I'll bet the bitrate is less than 147 kbps, and sounds better than your version 2.

See post 19:

I don't think you can ABX (3) and (2) - that is the core point of the discussion. You can try though. YMMV

foo_abx 1.3.1 report
foobar2000 v0.9.4.2
2008/01/18 07:54:59

File A: C:\Scorpions\Lovedrive\01 - Loving You Sunday Morning (V2 from V6).mp3
File B: C:\Scorpions\Lovedrive\01 - Loving You Sunday Morning (V6).mp3

07:54:59 : Test started.
08:02:41 : Trial reset.
08:02:41 : Trial reset.
08:02:42 : Trial reset.
08:04:44 : 01/01 50.0%
08:05:23 : 02/02 25.0%
08:05:27 : 03/03 12.5%
08:05:34 : 04/04 6.3%
08:05:45 : 05/05 3.1%
08:06:11 : 06/06 1.6%
08:06:26 : 07/07 0.8%
08:06:35 : 08/08 0.4%
08:06:44 : 09/09 0.2%
08:07:02 : 10/10 0.1%
08:07:09 : Test finished.

----------
Total: 10/10 (0.1%)

Let's hope that this finally puts to rest the myth that reencoding to a higher bitrate "does no harm".

Like with most things there's always a trade off.

This still doesn't mean there's no reason for a sane person to transcode to a higher quality level or bitrate, though I would never bother encoding a track like "Loving You Sunday Morning" at -V6 to begin with. -V3 to -V0 or -b320 for this track would probably be harder to ABX (unless you've got the acuity of guruboolez).