Can anyone explain, When I get this message form the MPC encoder:

WARNING:
There occured ** internal clippings due to a restriction of StreamVersion 7.
Re-encode with '--scale **', or use option '--xlevel', which normally can
handle this situation but don't work well with old decoders.

and I re-encode with the highest possible scale setting do I still keep volume diffrences from one
track to another or does it all normalize into the same volume now?.

Also can anyone tell me Which version of MPC I should be using?, 1.01i latest Alpha?, Beta?

well first off always use whatever encoder you can find at musepack.org

i keep that site fresh within no less than a day when a new one is released, and i will not post anything that isnt stable.

ok secondly that message means there is clipping occuring.

what scaling does is basically like reducing the volume by a set amount of decibels, so it adjusts whatever songs by the same amount of decibels, not to a certain percent.

if this message occurs a whole lot, you might be having trouble with ripping, as most cds do not really clip.

of course for ripping i suggest eac with whatever settings it detects for your drive.

another better alternative option to using the scale option is to use replaygain, as it is lossless and can be losslessly undone in case something changes.

basically you would encode the song, then run replay gain and given the proper settings it should automatically reduce each song so that there is no clipping.

hope this all helps you out

the encoder will recommend a scale setting...anywhere between .99 and .90...use it on just the one track unless it is closer to .90, then maybe do the entire album at the suggested scale if you want to preserve the audio level throughout the album... but then, i doubt it will be much of a difference, considering most of the album tracks are recorded differently anyways...



usually, frank klemm has posted binaries of the latest decoder and plugin [and always the encoder] on his site...i see no reason not to use the latest version, as currently the only changes have been bug fixes and tagging support, etc.
http://www.uni-jena.de/~pfk/mpp/

for latest decoder and plugin, roberto usually hosts an up to date mpc pack, compiled by john33 with ICL for speed:
http://www.inf.ufpr.br/~rja00/

later
mike

Thax guys for your help,

the encoder recommend a scale setting at 85 a few times I guess
I'll just scale all tracks when this happens

Better yet. Replaygain them instead

The majority of new album releases these days provoke internal clipping. You heard right, on some of today's "chart" albums, there's heavy clipping in the original WAV files!





No, Replaygain has nothing to do with this. This is internal clipping, i.e. clipping during encoding. This can only be solved by --scale xy or --xlevel (--scale preferred). Replaygain can only solve clipping during decoding.





This is currently the best way to solve it, until SV8 arrives with a fix.

People keep saying this, but I dont think that is true.

Replaygain works when clipping occur on decoding. This is because then all data is available in the encoded file.

The error message above inform about an internal clipping. This mean that data got lost because it could not be stored inside the encoded file. The information is lost forever...

The only solution is to use one of the methods from the error message.
There is a reason why replaygain is not mentioned in that message!

/Andreas

If Frank Klemm agrees with this, then --xlevel is redundant.

About decoding clipping:
I played a little with the debug function of the MPC plugin and found that replaygain headroom K-14 prevents all clipping on the songs I tested. Anybody found songs that need a higher K to prevent clipping?

Hmm. I guess you are right. I have wondered why replaygain wasn't mentioned when that error message appeared. Still an "official" statement from Klemm or Buschel would be preferred

In this case if one were to convert mpc -> wav, should one replaygain it first via --auto( if they are not replaygainED) to prevent clipping?

Yes, and then decode with clipping protection on.

Classical music often needs K-20...K-23.
Even some pop music with high dynmaics needs
K-18...K-23. Most I found was K-26. K-14
often clips for music I stored on my HD.

The other edge is K-2 ... 4.5 music, which I call
preclipped audio.

I'm confused by this. If the input wavefile is clipping at 0dB, is more information (less clipping) encoded if --scale is used during encoding than if no scale is set?

I think I understand how Replaygain can prevent decoder clipping... with loud (near 0dB) music, when the encoder removes some masked frequencies, then the amplitude of the waveform changes slightly and that can sometimes be enough to push the encoded signal over the 0dB mark. The signal goes over 0dB during playback, but the audio is still stored, unclipped, in the mpc file; it is simply the global gain value (the one adjusted by Replaygain) that causes the clipping. Is this correct?

Also, (and please correct me if I am wrong) .mpc (and .mp3) files store the amplitude data in floating-point format and then multiply that by some scaling value, which is why it's better to reduce gain after encoding, rather than before. If gain is reduced before encoding, then the source wavfile has less bits of accuracy (since the gain reduction causes rounding error and for the low-amplitude waves to be truncated). If it's reduced after encoding, then all the information is there, it's just multiplied by a smaller number. (Is this also right? I don't know how to distinguish between the file's allocated bits-per-sample and the "true" bits-per-sample of the file, which probably depends on the peak value and any dithering.)

So how does the encoder lose information during encoding that can only be kept by using --scale? If the source wavfile does not clip (with many samples at 0dB), then why would the encoder store the waveform with some set of values that approximates 0dB (before applying global gain)?

internal clipping is independent of replay gain and happens during encoding, not decoding. thta's why internal clipping needs scaling while encoding.
the problem is based upon internal signal representation. input signal is broadband, which is divied into 32 subbands. each of these subbands has a maximum amplitude, from which a so-called scalefactor is calculated (the "exponent" of the floating-point like signal representation). the amplitude of the subband samples may exceed 0 dB by far (depending upon amplitude, spectral and time-based type of the input signal). it is a fault of the sv7-design, that there is not enough headroom present to be able to represent the full scale of all these enormously raised amplitudes. if such a signal occurs, the encoder has to limit the calculated scalefactor to the allowed range. when decoding the effect is lowering the "overflown" subbands' amplitude by some dB.

andree

Does this mean that for an encoded (not pre-scaled) file with X internal clippings, on decoding those X clipping will be lowered in amplitude instead of "hard" clipped?

Are (non-corrected) internal clippings, "really" clipped or "merely" attenuated down when encoded?

so in this case, i was wondering is there a proper way of doing the decoding and when we're decoding any special switches involved?

lets say the scalefactor range does not fit the needed, then the subbandsamples will exceed the allowed range (+/- 32767) and the samples will be hardclipped! the decoder cannot reconstruct the original waveform (even if gaining it by -x dB).
that's why a re-encoding with the --scale switch is highly recommended.

When the encoder reports "x" number of clippings, is each clipping one frame (1152 samples) or one sample?

All of the internal clippings I've had occur were under 10 clippings, so I never bothered reencoding (I would have had to use a 0.830 scale on one track I've encountered). It would be pretty hard to pick out 10 samples if there's 44100 every second...

ok as everyone knows, im no programmer

(at least you ought to know, or else im sure i would have released tons of great software by now) **SARCASM DETECTED**

anyways i am wondering if it would be possible to make a program that would detect whether or not a wav file will suffer from internal clipping.

also maybe im retarded, but is there some way to have the encoder automatically scale the input wav file to the amount suggested?

thanks!

oh yea and by the way, can someone explain to me the --xlevel switch?

and in the encoder it says --scale x[,y]

what is the y value?

thanks again!

Regarding scale:
You can specify a different scale for each channel. So, --scale 0.50,1.0 will scale the left channel to half, while the right channel will remain untouched.

Regarding xlevel:
This allows for much higher scale factors. It works most of the time, but only with Klemm-based decoders (MJ plugin, mppdec). I have a track (Love You Madly by Cake) that still produces internal clipping with xlevel enabled.

Latest Winamp plugin 0.92l should handle --xlevel too. Changelog says it's untested, but atleast it worked on the sample I tried.

Here's my suggestion:

Adding a switch --autolevel to mppenc, which tells the encoder to do a 2-pass encoding.

So if there was any internal clippings it would automatically encode again with the suggested scale.

In the worst case, encoding would be twice as slow. But I think it would be a good idea since everyone is going to do the encode anyhow with --scale

i think an auto scale is a horrible idea...

but, whatever

later
mike

after so many posts, there are stilll no valid procedures

Clipping can still occure when decoding. To prevent this use clip protection.

I wonder why? As far as I can see this would be useful, and ReplayGain would 'correct' (or at least make irrelevant) the changed volumes anyway.

Would be very handy when using MPC from an interface (I always do MAC->MPC)

Edit: Uhh, probably wouldn't work as you can't seek a stdin stream

Any disadvantages?

--
GCP

Yes, the correction with replaygain would have to be title-based - you'd lose the volume differences between tracks on the same album.

More useful (well, for me anyway) would be to figure the lowest --scale 0.xx value, and then re-encode the whole album (=directory) using that value. Much slower though

If there's any way to find the --scale values without actually encoding the wavs, that'd be great. Is that possible?