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: klemms or buschmanns MPC (Read 10948 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

klemms or buschmanns MPC

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

klemms or buschmanns MPC

Reply #1 –
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

klemms or buschmanns MPC

Reply #2 –
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.

klemms or buschmanns MPC

Reply #3 –
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...

klemms or buschmanns MPC

Reply #4 –
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.
Juha Laaksonheimo

klemms or buschmanns MPC

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

klemms or buschmanns MPC

Reply #6 –
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?

klemms or buschmanns MPC

Reply #7 –
Heh. It's nice you pointed that.
Now I'm scared too.

Any official answer from Buschel/Klemm?

klemms or buschmanns MPC

Reply #8 –
Airborne, how much do they differ in size?

klemms or buschmanns MPC

Reply #9 –
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?

klemms or buschmanns MPC

Reply #10 –
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

klemms or buschmanns MPC

Reply #11 –
Thanks Kristo. Happy New Year to you too

klemms or buschmanns MPC

Reply #12 –
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.

klemms or buschmanns MPC

Reply #13 –
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

klemms or buschmanns MPC

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

klemms or buschmanns MPC

Reply #15 –
 

Quote
Originally posted by Speek
Thanks Kristo. Happy New Year to you too

klemms or buschmanns MPC

Reply #16 –
Quote
Originally posted by Dacs_IV
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.

klemms or buschmanns MPC

Reply #17 –
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.

klemms or buschmanns MPC

Reply #18 –
Hey Kristo!!!!

Its been a while since we talked on the telephone!

Happy New Year "RD"

klemms or buschmanns MPC

Reply #19 –
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 !!!

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

Quote
Originally posted by RD
Hey Kristo!!!!

Its been a while since we talked on the telephone!

Happy New Year "RD"

klemms or buschmanns MPC

Reply #21 –
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.

klemms or buschmanns MPC

Reply #22 –
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

klemms or buschmanns MPC

Reply #23 –
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

klemms or buschmanns MPC

Reply #24 –
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.....