APE 3.96b5, mppenc 1.01j, mppenc 1.01j, WinAMP plugins 0.92m, XMMS plugin 0.92
http://www.uni-jena.de/~pfk/mpp/ (http://www.uni-jena.de/~pfk/mpp/)
MPC encoder: http://www.uni-jena.de/~pfk/mpp/bin/mppenc-windows-1.01j.zip (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 (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 (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 (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 (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.
Originally posted by anubis
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
Originally posted by Garf
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:
'A lot of very important bugfixes (taken from the WinAMP improvements of the last 9 months) to make the plugin usable for XMMS users'
Make it usable!!
Note that there are a lot of features and bugfixes in the WinAMP plugin, which are not in the XMMS plugin.
I'd at least like the bugfixes, thankyouverymuch.
--
GCP
Originally posted by Garf
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.
- 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.
Originally posted by Frank Klemm
- report a bug you find in XMMS and I will correct it
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
Originally posted by Garf
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.)
You are using XMMS + MPC ?
[span style='font-size:9']edit: suing -> using[/span]
Originally posted by Case
They are not presets, they are options.
--stderr x write console messages to file 'x'
Thanks Frank!
G
Originally posted by Frank Klemm
You are using XMMS + MPC ?
Yes. I've upgraded to the newest version of your plugin, but it's still there. (This happened with the previous one too)
--
GCP
Originally posted by Garf
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
Originally posted by Garf
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 ?
Originally posted by Frank Klemm
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
Originally posted by Garf
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 ?
Originally posted by Frank Klemm
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 varies even in a single file. It either reports a frame number from 75-80 (mostly) or 45-55 (less often).
Probabilty larger or smaller ?
That does not seem to have affected anything.
--
GCP
Originally posted by Frank Klemm
How many bytes of the file are read after 55...80 frames?
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
Originally posted by Garf
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.
Originally posted by Case
Here is latest version of Winamp plugin inluding minor internal changes and working dithering: http://www.saunalahti.fi/~cse/in_mpc_0.92m.zip (http://www.saunalahti.fi/~cse/in_mpc_0.92m.zip)
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
Originally posted by ears
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?)?
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.
Originally posted by Frank Klemm
- 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
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.
Originally posted by Garf
When attemting to play a nonexistant file (e.g. in playlist but since then deleted) the WinAmp plugin crashes.
Thanks for reporting, it's fixed in version on my site.