Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "--scale .93" in 128 kb/sec preset clipping too mu (Read 4704 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"--scale .93" in 128 kb/sec preset clipping too mu

After some reading and experimenting, I found that a --lowpass of 15 or 16 will generate a higher volume which is shown in soundforge just by using your suggested command line. Lowering the --scale setting to 0.86 nearly obliterates clipping except in a scant few situations while your current reccommendation of 0.93 (in the --alt-preset cbr 128) is clipping for me so bad that I can clearly hear it hurting quality while 0.86 is clearly superior, especially for these high volume CDs coming out today.

My test song wasn't even the worst example of compression/volume either. The song I used to determine the best scale setting was Alanis Morissette - Thank U on her 1998 album Supposed Former Infatuation Junkie. (Most highly compressed pop-rock music you can buy today will be the same) When using your reccommended --scale 0.93, the last 20 seconds of the song are badly clipped and it's audibly causing saturation in the sound. Soundforge confirms the heavy clipping. With --scale 0.86, the clipping is totally gone. It's obvious that the lowpass is causing this increase in volume and that a lower --scale setting is necessary to offset the saturation.

When using Soundforge to check for clipping at various lowpass levels, I discovered the clipping was cut to nothing at these --scale settings and frequency cutoffs.  Feel free to encode your own mp3s, decode them, and review them in Soundforge if you think I'm wrong here, here's what I found:

--lowpass 15 or 16 = --scale .85
--lowpass 16.5 or 17.5 = --scale .90
--lowpass 19  or 19.5 = --scale .95

Didn't test a --lowpass 18, but behavior would suggest a setting of --lowpass .92 would be sufficient to inhibit clipping.

I would encourage everyone to look into what I've found and incorporate this into the presets.

mp3

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #1 –
I'm curious, whay does lowpassing raise the signal level?  Is it some kind of aliasing effect or something?

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #2 –
The --alt-preset VBR modes are never going to include a scale switch.  The reasons for this are:

1.  Clipping with VBR is much less of a problem than with ABR and CBR, meaning that it should very rarely be audible.
2.  mp3gain is a much better way of handling this than scale.

Also, you say lots of things are obvious, and certain things are for sure causing others, but I don't see any test files.  I tune the presets based on tangible evidence, which usually comes from test files... so the quickest way to get me to make a change to the lower presets is to show me a sample where there are obviously big problems in regards to what you say.

I'm also not really too interested in what Soundforge actually "says" about a file, I'm more interested in actual listening tests.

And btw, I have plenty of albums where to eliminate clipping (not necessarily audible clipping) with the --scale at a lowpass of 19.5, you'd need to go down to --scale .85 or less.. Scale just isn't the way to go to remove clipping then because I doubt most people wan't to use such a setting for all of their albums.

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #3 –
In the interests of being more PC, I won't bring this noise to your website Dibrom.  I've edited my post due to it's spicy nature.  My humble apologies on this matter.

mp3

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #4 –
Sorry to bump in just like that but I think too that mp3gain is a better way to avoid clipping that --scale.

EAC's normalizing routines are NOT so good, in fact it is known that EAC is a no-no for that (loss of quality, not hearable by any means but it's there). If you really want to use normalizing do it in Sound Forge or Cool Edit. Anyway, why normalize when we have mp3gain?

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #5 –
Quote
Whatever Dibrom. When are you gonna "blah blah blah..."


lol...is this what happens to open-source software...an "i thought of it first" type of attitude?

...egos

later
mike

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #6 –
Dibrom,

Quote
2. mp3gain is a much better way of handling this than scale


I have a question regarding this.  Is the information in the mp3 going beyond the point of clipping?  Is that how mp3gain recovers a clipped sample?  Because, as far as my experience goes, once you've clipped the sample there is no recovering the data lost above the peak threshold and any saturation or static artifacts caused by the clipping are permanent.  Are you saying that the mp3 format saves information beyond the peak and that data is recoverable?

mp3

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #7 –
Quote
Are you saying that the mp3 format saves information beyond the peak and that data is recoverable?


This is correct, which is why mp3gain is the best solution.

Added clipping in mp3's occurs when the encoded file tells the decoder to play something above full-scale.

ff123

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #8 –
Quote
Originally posted by mp3fan
Are you saying that the mp3 format saves information beyond the peak and that data is recoverable?
Yes, this is exactly it. I don't know what's the "internal accuracy", but it's greater than "16bit", so there shouldn't be internal clipping. The clipping happens in the decoding phase.
Juha Laaksonheimo

"--scale .93" in 128 kb/sec preset clipping too mu

Reply #9 –
Internal accuracy possible in mp3 should be aroud 130dB.