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: Frank Klemm on MPC and Time Resolution (Read 5491 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Frank Klemm on MPC and Time Resolution

After just browsing Frank's great MPC page (http://www.uni-jena.de/~pfk/mpp/), I came across a new short article some readers here may be interested in centered around time resolution of different encoders and how MPC stacks up in comparison.

You can read the article here:

http://www.uni-jena.de/~pfk/mpp/timeres.html

Most readers should find this interesting because the discussion is based around the ability of a codec to directly handle pre-echo at a theoretical level which is one of the most commonly discussed encoding artifacts on these forums.  I believe Vorbis should fall somewhere around AAC on this scale, but I don't know for sure since I'm not sure about it's window sizes.  Maybe someone can comment?

Some other interesting articles at his page:

http://www.uni-jena.de/~pfk/mpp/dither.html (article on dithering and noise shaping, both of which mppdec support)
http://www.uni-jena.de/~pfk/mpp/clipping.html (article on clipping)
 

Frank Klemm on MPC and Time Resolution

Reply #2 –
I've actually seen this site, but I'm not sure how correct the information there still is.  I believe it was based on beta4, and the RC's since then have gone through some very extensive changes.  I also remember that Garf was experimenting with different window sizes at one point.  Hopefully there will be an extensive overhaul on the documentation when 1.0 hits, as it would be interesting to know exactly what has changed.

Frank Klemm on MPC and Time Resolution

Reply #3 –
Why the sin(sin) window anyway...it doesn't seem to give perfect reconstruction

Frank Klemm on MPC and Time Resolution

Reply #4 –
On that site about time resolution Frank Klemm offers a nice test sample (Short_Block_Test_2.wav). Funny sound BTW. When you encode it with MPC -standard (I used 0.90n) you get a bitrate of 736!? It is really a difficult to encode sample. Apart from MPC with this ridiculous bitrate nothing is transparent.

Frank Klemm on MPC and Time Resolution

Reply #5 –
The good part is that this type of sample should never really happen in real music, but its certainly nice to know that MPC will scale to the occasion to encode it if necessary.

Frank Klemm on MPC and Time Resolution

Reply #6 –
FLAC and LPAC both compresses this test sample to about 7% of the size of the original. That is around 96 kb/s

Frank Klemm on MPC and Time Resolution

Reply #7 –
Quote
Originally posted by Dibrom
.. its certainly nice to know that MPC will scale to the occasion to encode it if necessary.

Let's see if it stays that way, (or maybe it wouldn't be necessary anymore?):
Quote
Frank Klemm about StreamVersion 8
An aim of StreamVersion 8 will be that 256 kbps are enough for streaming [..]. Currently there are pieces known which need much more than 230 . . . 240 kbps (the most wellknown is from Fatboy Slim).


Well 256 average[/b] is most often (more than) enough, even now with SV7 -xtreme.

Not that I worry about this, but it looks like the developers of MPC want to get rid of those ultra-high bit rate peaks.

I know, this is not the MPC section. Heck, not even the discussion section as I just found out.
--
Ge
In theory, there is no difference between theory and practice. In practice there is.

Frank Klemm on MPC and Time Resolution

Reply #8 –
I don't think anything is going to happen to MPC which will compromise quality.  Looking at some of the comments Frank has made about the modifications he is willing to make and how "carefully" they must be implemented, I think shows this.

What I think they'd like is to be able to handle clips like fatboy better than they do now at lower bitrates (who wouldn't want this?), but I'm pretty certain that doesn't mean MPC won't still scale.  If anything, it'll probably have a more "streaming friendly" mode which attempts to limit this is all.

Frank Klemm on MPC and Time Resolution

Reply #9 –
A little interesting bit of information Frank wanted me to share on the forum here:

Quote
> Please add the data rate of short_block_test_2.wav using bzip2 and bzip:
>
> bzip2:  2.3 kbps
> bzip:   2.1 kbps