I prefer quality, and i don't care much about speed. So should i use Klemm's or Buschmann's encoder?

I am willing to bow to greater knowledge, but I believe all, or nearly all, of the devlopment on all fronts is presently coming from Klemm, so I would suggest that is the best quality option.

If anyone knows otherwise, I would be very interested too!!

john33

Yes, use Frank's encoder. He is working with Andree (Buschel) and future developments will be done through his encoder. I believe he is now considered the "maintainer" of this project, as well as with the decoder.

Dibrom, just to be clear:
Is there any kind of difference in quality between the ever-updated encoder by Frank and the old Buschel one?
I have a tendency to become suspicious when something updates all the time, so I've been sticking with Buschel's encoder up until now...

No, there shouldn't be any quality difference. I believe Andree wants to be in charge of anything quality related. At least I hope he will inform if any quality tweakings is done.

ok, so you recommend i use the latest version of klemm's encoder, but what about replaygain... do you recommend its usage?

just one more question...
i was encoding my files with mpc a while ago with buschmanns encoder, and yesterday i downloaded klemm's version for WIN 0.90o.
The same tracks diferred in size even thouugh i used -insane presets on both of them. klemms version gave me higher bitrate.
is there any difference between the two encoded files. i am concerned because you have written that there were no changes in quality between klemms and buschmanns encoder- or was it?
did i miss something very important?

Heh. It's nice you pointed that.
Now I'm scared too.

Any official answer from Buschel/Klemm?

Airborne, how much do they differ in size?

I tried one song with -insane with 1.7.9c and with 0.98o and indeed they differ! The 1.7.9c encoded version has an avg. bitrate of 231.0 and the 0.98o encoded version has an avg. bitrate of 235.9. I read these bitrates from the Winamp File-info box.

Maybe John V has some inside information?

Buschel invented a new switch -ltq_max x after v1.7.9c
which sets a maximum level for ltq (default is: 83.0 dB)
I wouldn't recommend to change this setting.

According to Buschel the quality and bitrate used for certain passages will raise in rare cases since slightly more high frequencies are encoded.

But this is nothing to worry about !

Frank used this newer version from Buschel for his encoder version.

Kristo

Thanks Kristo. Happy New Year to you too

How are they measuring the "quality" and what is lacking that requires the bitrate to be raised? Is it simply adding upper registers that either no one or very few will hear? This sounds like the old war people were having about LAME and its lowpass filter and who can hear what.

I just encoded the same song with Andre's 1.7.9c and Frank's 0.90o encoders and there is a discernable size/bitrate difference. I'd like to hear someone explain the reason for this difference if Frank isn't truly changing the core encoding scheme, as I've been told.

Using 1.7.9c the results:
Bitrate: 220.8kbit/s, size: 5,950,404B.

Using 0.90o the resutls:
Bitrate: 225.5kbit/s, size: 6,076,656B.

This difference is only coming from the use of a new switch? It would seem logical that with improvements upon the codec the resulting files would be both the same or smaller in bitrate, and smaller in file size.

Bitrate could rise by a few kbits/s if encoder decides to code several more high frequency lines. I am not sure is this enabled by default (ltq_max of 83.0 dB) in Frank's new MPPENC but if it is it could be a reason for the bitrate difference between Frank's build and Andree's 1.7.9c


Remember - smaller the file size means more noise has been introduced (except we don't count some kind of prediction or losless coding improvement, which I think is not the case here) - so small increase in bitrate could mean small increase in quality

How do you figure smaller file sizes is resultant of more noise in the compressed file?

Because this is how psychoacoustic compression works. The more quantization noise you can add, the lower the file size you can get. The trick is to add the noise in all the areas which are inaudible... to do this you exploit the "psychoacoustic effects".

So theoretically, the best encoder in the world would be "noisiest" also, but you also wouldn't be able to hear this noise. By definition though, smaller filesizes (aside from better lossless phases as Ivan pointed out) means more exploitation of psychoacoustic effects which means more noise.

I would like to add small additions to Dibrom's post

- the process of introducing noise is called 'quantization'. By performing quantization we are rounding input signal and representing it with fixed number of bits.

The difference between quantized signal and original signal is called 'quantization error' and the squared difference is called 'noise'. So, the bigger the quantization error - bigger the noise.

Now, the 'smart' encoder decides how many bits are needed to represent signal with noise just below the threshold it would become audible. This is the job of the psychoacoustic model.

So, if the psychoacoustic model thinks that some frequency line needs higher precision the final result will require more bits and therefore we have increased bitrate for that signal.


By the way, these effects are really interesting - some experiments say that if we keep the noise 13 dB below the signal, most people wouldn't be able to hear the difference.

Hey Kristo!!!!

Its been a while since we talked on the telephone!

Happy New Year "RD"

Hey RD !!!

I'm currently working until tuesday!
I'll try to call you immediately after that and wish you a happy new year personally !!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

i will email frank about the difference in file size

I don't know what the heck I was thinking when I wrote that. Of course the better audio quality, usually the bigger the file. Duh.

Well, I'm using Frank's 0.90 encoder now. I've done tests on roughly 10-12 songs using both Frank's and Andre's and I can honestly say I hear no discernable differences for every song. Wondering out loud here, guys......this presents a conundrum to me. If the songs sound the same then why waste the space using Frank's encoder if I'm getting bigger files? I admit I'm not doing any r3mix type of analysis, but I have really good hearing and usually pick things up most others don't hear. What I wanna know is is there any type of special feature sets encoding into the files strictly meant for decoding using Frank's decoder? I know he's got the replaygain feature, though since I don't use it I forget if there's anything special encoded into the .MPC files to work with the replaygain feature. What's making these files bigger....is it all for audio quality?? Thanks for asking, Space. I really wanna hear what Frank has to say about this.

i havent heard back from frank yet, but maybe it does have to do with replaygain or something... perhaps there is space set aside for it...

also there is no clipping prevention information in the files made by frank's encoder (besides replaygain that is), but that would make frank's smaller wouldnt it?

ah well... i guess we'll have to wait for frank's response

here is frank's response:

----paste----
I've made some changes in the '--insane' profile around the 15th december.
There are some problems inside the ANS code which can decrease sound quality
so I disabled ANS for insane profile. This result in around 5 kbps more data
rate and increases speed. The current version (Linux only) supports a
selectable ANS order (not only off and on).

So I want to enable ANS with order 1 for insane in the 0.90r version. This
brings 52% of the bitrate save of ANS, but is more robust to the problems in
the current encoder.

--ans 0
%|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0 169.6 kbps 7.41x 2:57.5 2:57.5 0:23.9 0:23.9

--ans 1
%|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0 167.1 kbps 7.33x 2:57.5 2:57.5 0:24.2 0:24.2

--ans 2
%|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0 166.0 kbps 7.25x 2:57.5 2:57.5 0:24.4 0:24.4

--ans 3 %|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0 165.4 kbps 7.07x 2:57.5 2:57.5 0:25.1 0:25.1

--ans 4
%|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0 165.0 kbps 7.21x 2:57.5 2:57.5 0:24.6 0:24.6

--ans 5
%|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0 164.8 kbps 7.10x 2:57.5 2:57.5 0:25.0 0:25.0


Order [D(Order)-D(5)] / [D(0)-D(5)]
0 +100%
1 +48%
2 +25%
3 +12%
4 +4%
5 0%


The current problem of ANS is that the Noise Shaper is reset on every frame
boundary which reduces the effect of ANS. So the increase of the TMN is
over-estimated. It very rare cases it is also possible that ANS reduces
TMN instead of increasing it. I try to reduce this effect in some of the
future versions. This will be a deeper change in the encoder so listing
tests are necessary after this modification !!!!!!!!!

Current version will be different from the buschmann encoder. So
a higher quality but also new bugs or the need of tuning some parameters
inside mppenc are possible.

Currently I try to add support to encode a whole album with one command line
call:

mkdir mpc
mppenc --xtreme *.wav mpc

Main advantage should be that there are no click __possible__ between titles,
also on highly pathological samples. I don't know how this can be used from
GUI interfaces. They must not call mppenc file by file, but for a whole
album !!! This is because you need the last 256 samples of the previous file
and the 256 first samples of the next file to do a perfect gapless encoding.

MPC gapless decoding is much better than that of MP1/MP2/MP3/AAC (which have
an undefined latency and can add or remove up to 384/1152/1152/1024 samples
between tracks) and a lot of clicks I found were errors in the DAE from the
CD (or are part of the CD which is a hint of bit errors in the studio), but
there are some pathological samples where this is not enough (only a deeeeep
tone between the titles), so you can hear very silent but audible clicks
between titles at least using good headphones.
----end paste----

i havent read the whole thing but i figure it clears up the issue

Well, this reply worries me more than anything. I don't know what the "ANS code" does, and from what Frank says, it's not too clear if disabling the ANS results in a decrease of audio quality when using the Insane setting. I've been using the Insane setting since day 1. Regarding clipping, I use Audiograbber to normalize all my wavs and haven't noticed any clipping using Frank's .90o encoder. Maybe I should go back to using Andre's with the Insane setting............ man, I'm getting bad flashbacks of going nuts over what/who's settings were better for LAME, VBR vs CBR, etc., etc., etc.....

Why it worries you? Development still continues (which is a good thing), and regardless of some tweaks with ans, insane profile is still very high quality with or without ans tweaks. This issue is nothing compared to the quality differencies between different Lame settings or mp3 quality issues in general.

Don't normalize your WAV files, the quality isn't all that good... in fact, it's the worst way to reduce clipping. See http://ff123.net/norm.html on clipping prevention.

ANS is adaptive noise shaping and it is an attempt to push the noise that is added to a file into the inaudible region. the problem here seems to be that the code that picks what is inaudible or not resets for every frame, and it shouldnt.

its really nothing to worry about, as frank is quite capable of figuring it out.

Lol..no kidding...gives me the heebie-geebies, to tell the truth. However, the encoding as an album would actually be quite easy with Audiograbber. It allows you to "rip all tracks before encoding," so you could simply do that, and then run the mpc encoder as an external encoder. Nifty, no? And then no clipping

Obviously normalizing does change the overall sound somewhat, especially when using compression. However, I've found it quite reliable. I've tried other methods for volume control and nothing has ever seemed to work as well. I'm more worried about my encoder not representing every audible sound in the original wav/song, while keeping noise at a minimum. So far, my ears tell me MPC is the best for what I want to do. Sure, I could use Monkey's Audio or other forms of lossless compression, but the resulting files are way too big for my needs.

the best way to handle clipping problems is replaygain.

unfortunately i am still unable to use this on my computer for some reason

If they would just open the source...

i think this was discussed.....

personally i am glad they dont open the source.

then it ends up with mp3 and someone will make some really crappy encoder that everyone will uses (aka xing) and will mess up the format

Like Ogg Vorbis has gotten all messed up?

yes but look how long ogg has taken to develop

But look at ogg and lame. If someone like Garf thinks of a way to improve the tuning or Dibrom wants to fix bugs, they can. Which helps everyone. With closed source software, you're stuck with whatever you've got.

I agree. Keep the source closed. MPC/Musepack/MPeg+/whatever it's being called these days is the best sounding lossy format I've heard so far and opening up the source only brings about the neverending arguments about who's version is better, what commandline options are better, etc. and I really don't want to be subjected to that foray again. That's the other reason, besides the sound, that I like MPC. I use the insane setting from day-1 and it's sounded great on 99.9% of my music.