I have always used Variable Bitrate audio with a quality setting of Q=0.37
I decided to begin using Constant Bitrate at 128kbps for stereo audio and 320kbps for 5.1 surround audio since the Q=0.37 is a bit below that at around 92kbps to 120kbps average. (I tried Q=0.38 but then it makes it way too high at about 150kbps or more)
I have a Blu-Ray I ripped and when I encoded the audio with Variable Bitrate Q=0.37 it's fine. But for some reason when I encode using constant quality (No matter what bitrate I pick) Audacity says there is clipping in the audio file.
The DTS file or the DTS converted to .WAV or .FLAC doesn't have any clipping in it. It only seems to show up once the encoding with 128kbps constant bitrate is finished. The Variable Bitrate encode is unaffected.
I do not have normalization on and they both the same settings aside from one being Q=0.37 and the other a constant at 128kbps.
I'm not sure why it is doing this but it has me stumped.
+ Reply to Thread
Results 1 to 6 of 6
Last edited by killerteengohan; 2nd Jun 2015 at 21:05.
It seems to lessen or go away if I put a ridiculously high bitrate for stereo like 300kbps.
Does bitrate have an impact on clipping?
Due to the way lossy audio works if the audio has peaks at 0dB, after it's encoded and decoded it can have peaks slightly above 0dB. Not much (usually less than 1dB I'd imagine) but that's why some people recommend normalising to -3dB rather than 0dB to allow a little "headroom". When the audio is decoded to a wave file the peaks louder than 0dB would be "clipped" because wave files can only have a maximum of 0dB and that's probably what Audacity checks for. I think it imports the audio using 32 bit float rather than as a 16/24 bit wave file so the audio probably isn't clipped as such. I'm not 100% sure, but it doesn't sound like anything to worry about.
If the above is what's happening I'm not exactly sure why it's happening with CBR encoding and not VBR encoding in this case. I don't know enough about how lossy encoders work, but being "lossy" what comes out isn't exactly what goes in.
Are you using the Nero encoder? I kind of remember it can change algorithms fairly abruptly which means sometimes a tiny increase in the quality setting can cause the bitrate to jump a bit, but I also kind of remember sometimes the opposite happens. Somewhere there's a quality change in the 40's range (ie q0.42 to q0.43) where the increased quality setting actually reduces the bitrate before it climbs again as you increase the quality. I'm pretty sure....
Most of the AAC encoders can accept a 32 bit float input, which means the input can have peaks above 0dB and they'll happily encode it without clipping, although in this case that's probably not too relevant, but it'd mean any clipping would happen on the decoding/playback side. The encoded audio probably wouldn't be clipped, it'll just have peaks greater than 0dB. You could probably zoom in and check whether the peaks have been flattened out (clipped) but I don't know what software you're using for encoding or if the audio is being downmixed to stereo etc so I can only guess as to what's happening.
AAC is also like MP3 in that the volume of the audio can be adjusted without re-encoding (losslessly) so you could try that. If the audio is clipped before it gets to the encoder (which it probably isn't) you could reduce it on the way in to keep the peaks a tad below maximum, or reduce the volume of the encoded AAC audio to stop it being clipped on the way out. MP3Gain can adjust the volume of MP3 and AAC audio (it requires the AACGain modification but there's details on the MP3Gain site), and foobar2000 can also do it for MP3 and AAC. For foobar2000 you need to run a ReplayGain scan to determine the peak levels and it can adjust the volume from there.
This is what a foobar2000 ReplayGain scan looks like. The peak values are a percentage so a peak of 0dB would have a value of 1. Anything higher than 1 is potentially clipped on playback, but I think there's generally enough headroom for it not to be an issue. I don't think foobar2000 scans for "true peak" as it requires full decoding and it's therefore much slower, but R128Gain will. I haven't used it much.
The files below were adjusted to a ReplayGain level of 93dB for a special purpose and a limiter applied if necessary to prevent serious clipping. The ReplayGain standard is 89dB which is why a required reduction of about 4dB is shown for each one after scanning. Every so often there's a peak a little above 1.000000 or 0dB (it depends on the dynamic range and how much work the limiter needed to do etc), but the maximum peak of the third file in the list is the highest at 1.175204 and that means if the playback chain has no headroom at all there's a peak of 1.36dB above 0dB that might be clipped. It's never been something that's made my "things to worry about" list though. Converting percentage to dB is a little tricky but a peak level of 2.00000 would mean a peak of +6dB.
Foobar2000 can adjust the audio to the specified ReplayGain volume with an option to adjust it without allowing clipping if need be, or MP3Gain has a "maximum no clip gain" adjustment. I think MP3 and AAC audio can only be adjusted losslessly in increments of 1.5dB (up or down).
That's as much info as I can give you. Maybe someone else will have other ideas........
Last edited by hello_hello; 5th Jun 2015 at 03:40.
Last edited by hello_hello; 3rd Jun 2015 at 03:46.
I read elseware for quite a while and came across people saying that apparently Audacity shows clipping if the 0db mark is touched. So if it touches the top or bottom line it will show it as clipping even if its not going above or below the line. I zoomed in all the way and checked the clipping and most of it looks like it's only considering it clipping because its right on the line. Barely any looks like its above the line and the majority of the parts labeled as clipped or that are possibly above the line are only 0.000001 - 0.000015 seconds in length.
So I guess nothing to worry about for this situation.
Thanks for your time and info.