APE 3.96b5, mppenc 1.01j, mppenc 1.01j, WinAMP plugins 0.92m, XMMS plugin 0.92

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

MPC encoder: http://www.uni-jena.de/~pfk/mpp/bin/mppenc-windows-1.01j.zip
MPC decoder: http://www.uni-jena.de/~pfk/mpp/bin/mppdec-windows-1.01j.zip
Winamp 2.x plugins: http://www.uni-jena.de/~pfk/mpp/#plugins

What's new:
Monkeys Audio: Faster for Pentium classic (P5/60...66, P54/75...200) and Pentium 4
mppenc: New options --silent and --stderr
WinAMP plugin: All language versions compiled for a long time
XMMS: A lot of very important bugfixes (taken from the WinAMP improvements of the last 9 months) to make the plugin usable for XMMS users:
Album Based Replaygain can be selected
Gapless should work. Note that the old plugin never reconstructed the length exactly (like SV4...6).
Note that there are a lot of features and bugfixes in the WinAMP plugin, which are not in the XMMS plugin. A new XMMS plugin should be derived from the WinAMP plugin (best would be a unique source for both)
other unimportant changes

Here is latest version of Winamp plugin inluding minor internal changes and working dithering: http://www.saunalahti.fi/~cse/in_mpc_0.92m.zip

I have also uploaded compiled binaries of mppdec16, mppdec24 and mppdec32, available here: http://www.saunalahti.fi/~cse/mppdec_1.01j.zip

What do those 2 news presets mean?
Thanks.

They are not presets, they are options.
--silent do not write any message to the console
--stderr x write console messages to file 'x'

I'm encoding "braindeadly" because I'm sure Insane is useless (many headphones or good CD players cut over 20.000Hz).
Isn't Xtrem enough? I would like to be sure I won't have any problem about transcoding or playing my MPCs on good hardware but many people say that Xtrem is some kind of crazy preset yet and is very good for anything (even trans-trans-transcoding).
Do anyone know THE truth? Thanks.

There's no "THE truth" in perceptual lossy audio. Everything is subjective.

OK but if anyone had any suggestion...

XMMS source
- Not supported any more. Development dropped


So far for Linux support eh?

--
GCP

LoL . You conveniently left out the rest.. - XMMS source (current) not supported any more. Development dropped. Will be derived from the WinAMP plugin when WinAMP plugin becomes stable.

So obviously the old XMMS plugin source won't be supported, but a new XMMS plugin will be derived from the WinAmp PlugIn, when it becomes stable.

I left out the rest, because it was irrelevant to my point: Windows support always comes first, and if there's some time left and we feel like, we'll try to make a linux version as well.

Just read the original announcement and look for choice statements such as:



Make it usable!!



I'd at least like the bugfixes, thankyouverymuch.

--
GCP

- XMMS is unusable on my computer, it takes half an hour to
read my audio files
- When loading all my files in crashs
- It scrolls like a 4-bit computer
- Although there were nasty replay bugs, I never got a bug report
- This looks like noone uses MPC + XMMS
- Bugs in the WinAMP plugins are reported within minutes or hours, often by more than 1 person.
- report a bug you find in XMMS and I will correct it
- I don't keep in mind all bugs I fixed in the WA plugin
- Testing is nearly impossible due to the slow startup of XMMS

If the Linux user base wants an MPC plugin for XMMS, the source codes for the decoder and Winamp plugin are freely available.

Cool, you're going to program it?

--
GCP

Nope--I don't use Linux.

I'm often getting seemlingly random ' out of sync ' errors.

(I know this doesn't help much, but the 'seemingly random' part makes it kind of hard to track down. I know I'm not the only one with this problem either.)

--
GCP

You are using XMMS + MPC ?


edit: suing -> using

Thanks Frank!

G

Yes. I've upgraded to the newest version of your plugin, but it's still there. (This happened with the previous one too)

--
GCP

What must I do to genrate the error probably ?
I played 24 hours of MPC files and do not got any error message.

Hmm, I think it mostly happens just after a song changes. I can provoke it by rapidly clicking in the song list a few times, but it also happens spontaneously.

An example of the error I get:

Lost sync in file 'foo', Frame #69/8824

or

Lost sync in file 'bar', Frame #72/7874

The frame number is always small, suggesting it happens at the start of the file.

However, if click the song again, it will play without errors.

--
GCP

Is thsi possbile with evrey MPC file ? Or do it only occures with
some special MPC files which have some special properties ?

I can provoke it on all my MPC files. SV7, mix of xtreme and standard, ID3 tags

The frame number in the error dialog is nearly always around 75-80.
(On one occasion 55)

I cannot provoke the error if I set the output buffer to 1000ms instead of
default 2000ms, however, if I make it bigger/smaller, the frame number
stays in the 75-80 range.

--
GCP

How many bytes of the file are read after 55...80 frames?
Is the possible error frame the same for a given MPC file?
Probabilty ? 0.01%, 0.1%, 1% ?
Do files with loud starts have lower error frames, files
with gentle fade in higher?

It looks like it is associated with the first butterfly buffer
change.

Maybe you can reduce

#define MEMSIZE 8192

to

#define MEMSIZE 2048

and compile it. Probabilty larger or smaller ?

It varies even in a single file. It either reports a frame number from 75-80 (mostly) or 45-55 (less often).



That does not seem to have affected anything.

--
GCP

I added an extra BitsRead() display in the error dialog box and the number varies widely between 200000-400000 bits read.

Edit:

Err, I fiddeled more and the error does not seem to be generated by the code! The FrameWasValid var seems to get reset to 0, even if I force to code to make it -1 (I also made it signed int of course). Could this be a threading problem?

Edit 2:

Typo in the Makefile: -DREENTRANT should be -D_REENTRANT. However, this does not fix the problem.

Edit 3:

Ok, I _think_ I got it. I changed the FrameWasValid var from a global to a local in the decode thread function, and then passed it to DECODE via a pointer. I get no more errors and the files seem to play fine. Could this be some kind of race condition between closing the old decoding thread and starting a new one? That would explain the behaviour I think.

--
GCP

Send the code changes to my home (university) address. I will check this. The main problem was that I never got this error
message.

Case,

I was just wondering what improvement can be gained by using your compile over Klemm's 'official' release? Is dithering not properly implemented in Klemm's version? What type of dithering are you implementing (shaped triangular?)?Thanks.

Maybe just triangular...although shaped triangular is better. BTW, thanks, Frank, for a great encoder. I've been enjoying it for months now, and I'm very glad I found it. I know that developers hate this question more than anything, but is there any ETA for the Stream Version 8 encoder? I still have some files I have to scale down to keep from clipping them, would love to be able to just leave my computer to rip/encode by itself, without babysitting it through the whole process.

When attemting to play a nonexistant file (e.g. in playlist but since then deleted) the WinAmp plugin crashes.

--
GCP

Well, the compile I posted is later build with some internal changes plus bug fix with dithering. Dithering routines were never called (probably in any) previous version. Frank has changed dithering from triangular distributed white noise to triangular distributed triangular shaped noise since official 0.92m and that's in use with my build.

I and several of my friends use mpc exclusively on Linux. If we lost xmms support, we'd have to go back to vorbis. Please keep xmms support! I'd be happy to help with porting and testing.

Thanks for reporting, it's fixed in version on my site.