Converting MP3->WAV->MP3: would it always lose something each time?

Factual Questions
1

I am familiar with lossy compression schemes like JPEG, where converting from a TIF format to JPG, then back to bitmap, then JPG – each time the JPG compression is done, the image deteriorates and some data cannot be recovered or reconstructed.

But is this true with MP3 conversion from a WAV-type sound file also? Would repeated encoding->decoding->encoding cause irreplaceable, cumulative data loss?

At first glance, it would seem so. But I can envision a compression scheme so designed that the elements added during expansion are exactly the same elements ignored during subsequent compression, so it would not accumulate losses beyond the first cycle. I just don’t know if any non-theoretical scheme works this way.

2

a) You cannot design a compression scheme that can add elements in during expansion that are identical to the ones that it discarded during compression. Lossless compression encodes data in such a way that nothing is discarded, just scribbled down more efficiently. Lossy compression discards. That which is discarded ain’t there no more.

b) If you use VBR compression to create an MP3, and set it on the very highest quality setting, you discard very very little that has any real impact on the sound to be reproduced. (Translation: you don’t need 360 bits per second to properly encode a second of dead silence). You could take such an MP3, convert it to WAV or AIFF, then turn around and recompress it to VBR MP3, and not be able to tell the difference between it and the original MP3. You could probably do so several times, in fact. But eventually you’d have sonic artifacts and other consequences of lossy compression.

3

I agree that such a scheme could be designed, but without making this a requirement, it probably won’t just happen. It would be especially interesting if the only the decoder needed to be modified. i.e. the MP3 -> WAV decoder could be designed to add in small perturbations to its output just so that the WAV -> MP3 part would return the identical MP3 you began with. I personally don’t see a use in this, but maybe there is one.

4

[QUOTE=AHunter3]
a) You cannot design a compression scheme that can add elements in during expansion that are identical to the ones that it discarded during compression. Lossless compression encodes data in such a way that nothing is discarded, just scribbled down more efficiently. Lossy compression discards. That which is discarded ain’t there no more…
[/QUOTE]

That’s not exactly what he’s asking, though.

Assume that I’ve got a long sequence of digits, and my compression scheme is to replace all digits that aren’t 7-9 with a zero, then run length-encode (or some other type of scheme) to compresses the result. This is clearly lossy, and would give me moderate compression on randomish data.

So 0123456789 would become 0000000789, and compress to about 5 “digts” after RLE, for a lossy ~50% compression to something like: 07789, where the first “7” is the number of zeros. (Admittedly this is a particularly good case since the 0’s become contiguous). This is analgous to the MP3 conversion in the OP’s question, and what AHunter was talking about. Clearly non-reversable.

However, the OP is asking whether expanding that sequence, storing it in a LOSSLESS format (WAV in this case), then recompressing into the original would increase the loss. We can take out the lossless compression/decompression, since it by definition does not cause loss.

Continuing my example above, if we take the post-compression 0000000789 and re-encode it using the same algorithm, we get…0000000789 - i.e. even though we used a “lossy” algorithm, there was no further loss because the data we’d have stripped was already gone.

The OP’s question is: does MP3 encoding have this property: i.e. does encoding an MP3 file twice with the SAME SETTINGS further degrade the sound.

I don’t know the answer, but hopefully I’ve clarified what I believe was meant by the question.

5

[QUOTE=Musicat]
I am familiar with lossy compression schemes like JPEG, where converting from a TIF format to JPG, then back to bitmap, then JPG – each time the JPG compression is done, the image deteriorates and some data cannot be recovered or reconstructed.
[/QUOTE]
Emphasis mine.

I don’t think this is possible. It may degrade more each time for a certain number of cycles, but there is a finite amount of information encoded in a jpeg (or mp3). It’s not possible to lose data on every cycle forever.

As a first approximation of a test, I did the wav->mp3->wav process 4 times. Each successive mp3 file was about 1.5 KB larger than the previous iteration, so, assuming that the mp3 headers aren’t really stupidly designed, the data encoded is changing. I couldn’t say what the sound quality is like, but if nobody tests this by tonight, I’ll write a script to do the encoding/decoding a few hundred times. That should give a more interesting result.

6

Timewinder is getting closer to what I had in mind.

I use WAV format as an example of a lossless storage scheme which, even if compressed, will not lose anything when expanded (like a TIF or BMP image file).

I know that MP3 discards info, and the amount discarded can be somewhat controlled by specifying the bitrate, but even the best quality results in some non-recoverable loss, at least the first time it is compressed.

My question was if subsequent expansion->recompression->expansion->recompression would eventually, given enough times and low enough settings, result is degradation that could at least be measured or detected (by examining the data), if not heard. Just like JPG artifacts that creep into many images.

Or if what was reconstructed during expansion (to make a file playable) was possibly the same data that was subsequently discarded the next time around. If so, than successive cycles would not increase the loss compared to the first compression.

If you say this is not how MP3 works, then this is more of a theoretical question than a practical one; could such a scheme be possible?

7

How would the compression algorithm know what the heck had been discarded in a previous iteration of compression / re-expansion? Obviously, it wouldn’t, so the only way this would work is if the algorithm always chooses the same information to keep (the first time throwing away data that is “actually data”, albeit perhaps relatively meaningless; and all subsequent times throwing away “ersatz data” that was created when the AIFF was generated from the MP3).

I suppose it’s possible that it actually works that way, or could work that way, but I don’t think it necessarily works that way.

I just took a small JPEG image (attached to a piece of incoming spam) and opened it in Photoshop. Saved as TIFF (non-lossy). Original size = 443 x 246. Changed image size to 4400 x 500 (nonproportional, obviously). Changed image size back to original. Saved. Repeated, using different image sizes but always with HIGHER figures than the original, never converting the file to fewer pixels in either direction that it started out with. In each case that I created a larger image, Photoshop was interpolating from data it did have to generate data in places where the original image didn’t have places. The same program, when asked to resize it back down, did not reliably discard the exact same “made up” data that it created in the prior step — instead, it did its best guesswork to scale it down, treating the “made up” data as having the same validity and usefulness to the image as the data that had already been there. (Because it had no way of knowing, see?)

Result: image degrades.

(Note that in this case the original image was no great shakes. It started out with artifacts visible at this resolution. Still, you can see that resizing UP and then resizing back to ORIGINAL size does degrade the image. Data does get lost)

8

The compression algorithm (WAV –> MP3 converter) wouldn’t have to be changed. But what the OP seeks would require a particularly smart expanding algorithm (MP3 –> WAV converter). Given an MP3 file.mp3, the expander would need to compute a nonempty subset of all the WAV files that would get mapped to file.mp3 by the compression algorithm. The expander would generate its own output by choosing one of those WAV files.

9

[QUOTE=Tyrrell McAllister]
The compression algorithm (WAV –> MP3 converter) wouldn’t have to be changed. But what the OP seeks would require a particularly smart expanding algorithm (MP3 –> WAV converter). Given an MP3 file.mp3, the expander would need to compute a nonempty subset of all the WAV files that would get mapped to file.mp3 by the compression algorithm. The expander would generate its own output by choosing one of those WAV files.
[/QUOTE]

That would be practically (if not literally) impossible. Any given MP3 is the result of interpolating down from an unknown number of AIFFs. Let’s say we go with 10. So…we store, in the executable or its library folder, 10 possible full-sized AIFF files for every conceivable MP3 file that could ever exist?

10

I wasn’t proposing that there would be 10 (or even 1) AIFF file for every possible MP3. I said that the expander would compute at least one WAV file that, were it to be encoded as an MP3, would produce the original MP3. I have no idea how feasible this computation would be. Someone with more knowledge of the particulars of the MP3 encription algorithm would have to answer that. But TimeWinder already showed that it is in principle possible in post #4.

11

I’ve tried converting MP3–>WAV–>MP3. I used Audioconvert to go from WAV to MP3 and musicmatch to convert back.

I had already copied the CD to MP3 at 256 Kbps and then just kept converting back and forth, always at 256 Kbps.

After 60 conversions (ie: 30 each way) the newest MP3 seems to be a little worse than the first, but only slightly. The files sizes steadily grew, the last MP3 was 20% larger than the first.

I was surprised that the conversions heald out so well.