checking an mp3 for clipping [how to/questions]

If an mp3 [copy] imported into audacity shows clipping does that mean it was clipping before or could it be the decompression process that caused the clipping?

I am trying to check my mp3’s for clipping. So could I make a copy of an mp3 just to check? (since decompressing and recompressing original would be harmful). When I first started checking I didn’t realize that importing then exporting mp3’s into audacity degrades [harms] them BUT I did notice some of my mp3’s clipped and some didn’t when viewed in audacity. These are downloaded [studio released] mp3’s from Sony/Freegal (not audacity created) and as stated some show clipping in audacity some don’t. I don’t know of any other way to check them and I suspect they are clipping and want to be sure.

I also downloaded Mp3DirectCut which allows you to reduce gain without decompressing BUT it doesn’t seem like Mp3DirectCut shows if it is clipping or not. I even created a clipped mp3 with audacity and when viewed in Mp3DirectCut I could see no sign that it was clipping (e.g., red lights, lines, etc.).

So (1) is importing an mp3 copy into Audacity an accurate way to check for clipping?
and (2) (If someone might know) is there a way to check for clipping with the Audacity recommended “Mp3DirectCut” (freeware)?

response greatly appreciated, [thank you all]

Audacity imports EXACTLY what was in the file. If, after import, the file shows clipping then it was there in the original. My understanding of MP3, an understanding that may be inaccurate, is that there is no “decompression”. It isn’t like a ZIP file, which is compressed when written and saved, and then uncompressed when it is read into UNZIP. With MP3 it gets compressed into a new sound file, which thereafter is what gets used.

My understanding is that encoding audio as MP3 is a lossy process and decoding an MP3 accurately reconstructs that encoded data. The data loss occurs during encoding, not decoding. If there is any clipping damage in the MP3 then it’s too late to do anything about it.

There is however a possibility that if something has been recorded extremely loud (see loudness war) then it may be subject to additional clipping/distortion by the playback system being unable to handle the extreme (possibly over 0 dB) level. The best way to combat this is to use ReplayGain (available on many MP3 players) or Sound Check (iTunes) to control the level to which it is decoded.

My mistake: “re-compression” is not the problem/term _but rather re-encoding!! the problem is loading an mp3 into audacity editing it and then exporting it degrades it! due to re-encoding --so there is software like mp3DirectCut which allows some editing with out the de- and re-encoding.

Now as far as clipping – I am still unclear on all the ins and outs, from a laymans perspective that is …
Mp3DirectCut never seems to show clipping … in it’s normalizing window, I’ve yet to see an mp3 go beyond 0, I’ve seen them maxed to 0 and those same maxed mp3’s will be in the red when loaded into Audacity!! - some way in the red! – I don’t get it.

So now I’m just listening (going by ear) – Does Windows Media Player and the like fix as they play? with “volume leveling” and what ever other term(s) other players use for volume leveling? So many questions, I need a book on the subject I guess. Yeah, I’ll research “Loudness Wars”, thanks. Besides the studio released mp3’s I have, that clip in Audacity, I want to know for my own music I make. --I mean why go -3dB with an mp3 if the studios aren’t doing it?
It may be a German thing! the crafty Germans invented the mp3 I guess. And maybe a lot of people over-here just don’t know exactly what they’re doing pushing everything to 0 and possibly even beyond? (or maybe they do?) – /-1dB (for wave) does seem to sound better – but I’m not sure!, and then there does seem to be a ‘needs more volume’ issue a lot, yes even with using the compressor efect – not sure if this was a rant or a question!! -thanks.

Here’s a relevant qoute from wiki.audacityteam.org:

“Re-encoding to MP3

Every time you export from Audacity as an MP3 (or other lossy audio format), this encoding necessarily degrades some of the original quality of the audio. If you import an MP3 into Audacity, edit it then export it as an MP3, you are thus losing quality twice - once in the original MP3 encoding of the imported audio, then again when you export it from Audacity as MP3. Therefore when you are exporting as MP3, work with the highest quality copy of the audio that you can - preferably a copy in a lossless format such as WAV, AIFF or FLAC. You can always obtain a lossless copy of an audio CD by extracting its audio to a WAV or AIFF file. Never extract the audio from a CD to MP3 if you want to export it from Audacity as an MP3.

If you can’t avoid importing an MP3 into Audacity and then re-encoding to MP3, don’t believe what you sometimes hear that using the same or higher bit rate as the original file will prevent quality loss. This is incorrect. All you can say is that the higher the bit rate you re-encode to, the less will be the quality loss that results.

If you only want to perform simple edits on your MP3 (cut, copy, paste, join, fade or normalise), you may prefer an application that can edit MP3s directly without having to decompress then re-encode them as Audacity does. Examples:

MP3 DirectCut for Windows
Audion for Mac OS 8, OS 9 and OS X or Macsome for OS X
Mp3Splt for GNU/Linux.

For more advanced edits such as effects, the audio needs to be decompressed in an editor like Audacity, so you must then accept any perceptible quality loss from re-encoding the MP3.”

Missing features - Audacity Support

That is the ultimate test. The whole point of music recording is how it sounds. The rest is just an explanation of why it may not sound as good as we would like.

MP3DirectCut has a different method of rendering the waveform display. It’s not that clipping will not occur on decoding, just that MP3DirectCut does not show clipping (MP3DirectCut does not decode the MP3).

It is only possible to have “over 0 dB” in floating point formats. The greatest sample value possible in integer formats is +/- 1.0 (to be pedantic, the maximum possible positive value is a tiny bit less than +1 due to the asymmetry of signed binary integers).
If decoding an MP3 produces a sample value greater than +/- 1, that fact will not show up unless/until that sample is calculated as a floating point numerical value. MP3s can produce values greater than +/- 1 but only if decoded as floating point values. In integer formats (eg. 8, 16, 24 bit) there are two possible ways of handling out-of-range numbers; either the number can be “wrapped” (positive numbers become negative and negative numbers become positive) or the value can be truncated (clipped) to the maximum/minimum value. In audio it is preferable to clip to 0 dB than to wrap.

Because Audacity works internally in 32-bit float format, there is a third way to handle over 0 dB samples and that is to represent the full, over 0 dB, value. The audio may then be clipped to 0 dB by converting to an integer format (this will happen if you import an MP3 and then export it as a 16 bit WAV file) or you can amplify the entire track by a negative amount so that all sample values are scaled to lie within the 0 dB range. Scaling the values to lie within 0 dB is arguably the most “true” method, but in practice the difference between that and limiting values to +/- 1 is negligible/inaudible.

I’ve not tested, but I would expect that sample values would be limited to 0 dB, that is, if decoding the MP3 produced a sample value of +0.03 dB then decoding it to an integer format (required by the sound card) would produce a value of 0 dB (a tiny bit lower than it really should be, but probably not an audible difference).

That “Loudness War” article on Wikipedia explains why.

Just because industry does something a certain way does not mean that it is the best way - for example, who uses aspartame or hydrogenated vegetable oil in their home cooking?