The Musepack SV8 beta is out.
To quote from the official musepack.net forum post (http://forum.musepack.net/showthread.php?p=1649):
This is a beta of the format's stream version itself and not just the codec's accompanying applications. SV8 is complete, but it needs to be finalized. There is a chance that some bugs have gone unnoticed. The purpose of this beta release is to allow wide-scale testing before the new stream version is finalized. Your participation is essential.
We don't recommend that you start mass-encoding or converting SV7 files to SV8 just yet. If changes to the bitstream will have to be made, they may break compatibility with files created by the beta version. After the public beta testing period is finished (the period of time depends on the findings) and the final version is released, you could safely encode and convert.
Users: if you encounter any trouble with either mpcenc, mpcdec, mpcgain, mpccut, or mpc2sv8, feel free to report it.
Developers: if you have any question to ask, problem to report or patch to submit, feel free to do so.
Package contents:
mpcenc - Musepack SV8 encoder
mpcdec - Musepack SV8 decoder sample application based on the latest decoder library
mpcgain - Musepack SV8 ReplayGain utility based on our new ReplayGain library
mpccut - Musepack SV8 stream cutter
mpc2sv8 - Musepack SV7 to SV8 lossless converter
Changes:
- Packetized stream allowing muxing into audio and video containers (e.g. MKA, MKV, NUT)
- Streamable
- Sample-accurate, fast seeking independent of file length
- Sample-accurate cutting
- No internal clipping. --noxlevel flag removed, not needed anymore
- Bitstream compressed by highly optimized canonical huffman tables - 2% smaller files and faster decoding
- Cleaned up and rearranged code - libmpcdec, libmpcenc, libmpcpsy
- Removed input from audio card (OSS)
SV8 stream options:
--no_ei - do not write encoder information packet (default: off)
--no_st - do not write the seek table (default: off)
--num_frames x x = 0..7 - number of frames in packet = 4^x (default: 3)
--seek_distance x x = 0..15 - keep a seek table entry every 2^x audio packet (default: 1)
SV8 specification (http://trac.musepack.net/trac/wiki/SV8Specification)
Download:
Windows package (http://files.musepack.net/windows/Musepack-SV8-beta-Windows-2007-09-23.zip)
Source code (http://files.musepack.net/source/libmpc-r352.tar.bz2)
To test SV8 files, you can use the newly released foobar2000 beta (http://www.foobar2000.org/beta/).
Naturally, while SV8 is capable of being used in a new range of applications, support for it has to be implemented in them first. Applications which already support SV7 will have to be updated to allow use of SV8 files.
Enjoy :-)
wOOt, thank you!
I encoded a few files and it seems Ok. Bitrate is back to 1.14 levels or so it appears...Good work.
great news! lossy king is back!
thank you, love musepack
Interesting news. Wanna see how this pans outs...
Does this update affect sound quality, too?
I'm not an MPC user, but I it's great to see development of this oldie but goodie being continued.
Sure there are alternatives nowadays, but it's an excellent codec, and one of the most interesting ones for Rockbox users.
Thanks for the update.
I have done some testing and so far everything is working fine.
A nice surprise was that mpc2sv8 created smaller files than the original source (musepack 1.14).
Are mpcdec and mpc2sv8 feature ready?
If so mpcdec is not working to stdout and for mpc2sv8 I'm missing an option to overwrite the same filename.
Well, well, I didn't really expect this! Good news, indeed.
If the new SV8 makes its way to Rockbox soon with good performance, MPC might return to my books again!
Anyway, I have a bug to report... Not sure whether it belongs here or on the foobar2000 forum, but the point is that when using the new foobar2000 beta to encode (after renaming mpcenc.exe to mppenc.exe and pointing the program to it), the encoding process hangs and nothing happens. Perhaps it's entirely expected, but in any case it's something someone will have to fix eventually.
Kudos for the release, guys!
Wow! I had almost given up hope!
Fantastic work guys.
WoW!
Musepack forever!
Thank you, MDT!
p.s. -Nepomuk-, there are more than a few freaks are using it.
I had given up to expect this in my lifetime, nice surprise. I wonder if there are still enough users to help beta-testing
Anyway, I have a bug to report... Not sure whether it belongs here or on the foobar2000 forum, but the point is that when using the new foobar2000 beta to encode (after renaming mpcenc.exe to mppenc.exe and pointing the program to it), the encoding process hangs and nothing happens. Perhaps it's entirely expected, but in any case it's something someone will have to fix eventually.
--noxlevel flag removed, not needed anymore.
Remove --xlevel from foobar's convert options in mpc custom mode.
Thank you for this update. Now the most serious disadvantage compared to MP3, the inability to cut the stream, is no more.
Will the new version only be compatible with Foobar 0.9.5 and the "official/native" non-backwards-compatible Winamp 5 plugin? That pretty much locks me out.
To the guy saying MPC is dead: I would say MPC is too "alive" compared to Mp3; compatibility has been broken so many times with different StreamVersions. On the other hand if the codec was complete, meaning the frame based structure of MPEG was kept, then there would be no need for regular updates; it would just work. Like MP3, AC3.
Thanks a lot! I'm really glad to see this happen
I had given up to expect this in my lifetime, nice surprise. I wonder if there are still enough users to help beta-testing
I believe there are
~
I managed to crash mpc2sv8.exe
Command line: mpc2sv8.exe e:\a.mpc d:\
System: XP SP2
Description from event viewer:
Faulting application mpc2sv8.exe, version 0.0.0.0, faulting module mpc2sv8.exe, version 0.0.0.0, fault address 0x0000ad2a.
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 6d 70 63 ure mpc
0018: 32 73 76 38 2e 65 78 65 2sv8.exe
0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0
0028: 20 69 6e 20 6d 70 63 32 in mpc2
0030: 73 76 38 2e 65 78 65 20 sv8.exe
0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0
0040: 61 74 20 6f 66 66 73 65 at offse
0048: 74 20 30 30 30 30 61 64 t 0000ad
0050: 32 61 0d 0a 2a..
Musepack lives and it still rocks - thank you!
Thanks for the update, guys, this is very appreciated!
I didn't think this will ever happen. It's a very good news. I'm just wondering about following things:
How much work will it be to add support for MPC to MKVToolnix? And then we will also need a DS filter to play those files.
I managed to crash mpc2sv8.exe
Command line: mpc2sv8.exe e:\a.mpc d:\
System: XP SP2
I managed to replicate it. It indeed crashes. Keep in mind, though, that you have to provide the name of the out file (or DriveLetter:\NameOfFile.mpc) and not just a path. We'll fix it.
Will the new version only be compatible with Foobar 0.9.5 and the "official/native" non-backwards-compatible Winamp 5 plugin? That pretty much locks me out.
There is a plugin for WinAmp 5.x that supports both SV7 and SV8 files. We'll prepare it for release soon. It is not going to be maintained by us, though. The devs cannot spend time on side projects like this one.
Nobody answered my question... So, if this update also affects quality, is MPC optimized for certain bitrates - or maybe the other way round - are there any bitrate ranges where MPC should not be used?
Nobody answered my question... So, if this update also affects quality, is MPC optimized for certain bitrates - or maybe the other way round - are there any bitrate ranges where MPC should not be used?
Other than the fact that SV8 handles internal clipping without hacks which results in a slightly different output in some cases, the psymodel hasn't changed. The encoder should be used just like previous versions.
I'd like to report the space savings converting to sv8 (11KB on a 4.01MB file) and that the conversion process was very fast. According to the bitrate of a native sv8 file and a converted sv7 (version 1.16) file there was not a noticeable difference in overall bitrate.
Thanks: MDT, musepack developers, FB2K developers, MPC testers
This is excelent news.
What do you mean when you say "no internal clipping". Does it mean that we don't have the clipping upon decoding that happens with lossy files?
I will repeat my findings with mpcdec.
mpcdec doesn't decode to stdout but writes to the file: -
mpcdec test.mpc - | …
Is decoding to stdout not implemented yet?
I will repeat my findings with mpcdec.
mpcdec doesn't decode to stdout but writes to the file: -
mpcdec test.mpc - | …
Is decoding to stdout not implemented yet?
nope, mpcdec is more a basic sample application. There are many apps, like mpc123 or cmus, that will offer much more options to play mpc files through command line. Libmpcdec external API haven't changed much so hopefully, they'll update relatively easily
The "not implemented" part is correct. The "yet" part depends on our main dev. I know it is an important feature for some and we won't ignore requests.
The "not implemented" part is correct. The "yet" part depends on our main dev. I know it is an important feature for some and we won't ignore requests.
Ok thanks,
I will follow the development.
Just like an old girlfriend. I thought I was over her years ago, and then I run into her at a party, and all those old feelings came right back
It's worth to remember that many of you were bashing MPC and decreeting its death on a couple of topics sometime not so long ago. And it has never been this way.
It's worth to remember that many of you were bashing MPC and decreeting its death on a couple of topics sometime not so long ago. And it has never been this way.
Would the "you" be people on this board, or people that have posted to this thread? I searched and didn't come up with any MPC bashing in my former posts, though it's entirely possible I did at one time.
Edit: I believe that the seeking issue was my biggest complaint, as it caused issues with some very large files. If that is fixed, that would be huge for me.
Foobar2000 0.9.4.5 beta 1 is out with Musepack SV8 decoding support
http://foobar2000.org/beta/index.html (http://foobar2000.org/beta/index.html)
http://foobar2000.org/changelog.html (http://foobar2000.org/changelog.html)
It's worth to remember that many of you were bashing MPC and decreeting its death on a couple of topics sometime not so long ago. And it has never been this way.
It's human to err. The release of SV8 is proof enough for them, don't need to rub it in.
Get on with the testing!
Edit: I believe that the seeking issue was my biggest complaint, as it caused issues with some very large files. If that is fixed, that would be huge for me.
Wasn't there already some sort of a 'hackish' fix in FB2K since 0.9.4.2? The worst effect would be high frequency noise that almost nobody would notice. I was already enjoying fast seek with SV7 because of that.
indybrett, yeah I saw you naysay on MPC.
the "you" people I talked about is actually you... LOL
But you are forgiven...
Now bowdown to MPC!
God and I thought MPC was dead and buried although being a great encoder Nice to see folks still working on Musepack.
I would like this thread to not degrade to a level of accusations. SV8 exists because a few people found it challenging and fun enough to work on and believed the format could be improved. We want others to enjoy it too, and format wars aren't going to help with that.
We're not an organization and none of our devs can work full-time on the project. We're doing the best we can to provide tools that allow to test the new stream version. The source is there so programmers could write apps like a GUI that uses mpc2sv8. We will concentrate on development of the format and I promise to write down any request so we could evaluate which of those is practical, given our severe lack of manpower.
seed, can you explain what means 'no internal clipping'?
is this the solution to the karma all lossy codecs face - and the reason we use MP3Gain, for instance?
It's worth to remember that many of you were bashing MPC and decreeting its death on a couple of topics sometime not so long ago. And it has never been this way.
It's human to err. The release of SV8 is proof enough for them, don't need to rub it in.
Get on with the testing!
Edit: I believe that the seeking issue was my biggest complaint, as it caused issues with some very large files. If that is fixed, that would be huge for me.
Wasn't there already some sort of a 'hackish' fix in FB2K since 0.9.4.2? The worst effect would be high frequency noise that almost nobody would notice. I was already enjoying fast seek with SV7 because of that.
Can you send me a link via PM? I can't recall what it was, and don't want to derail this thread.
Indy forget about it... I just made that comment because I thought it was unfair. You yourself admitted you might have done that once maybe. I'm gonna respect Seed's wish and not start any further discussions.
seed, can you explain what means 'no internal clipping'?
is this the solution to the karma all lossy codecs face - and the reason we use MP3Gain, for instance?
As far as I know, MP3Gain's purpose is to apply values which allow to losslessly normalize the music's volume and make all tracks sound equally loud. This is not the same as --xlevel which was a hack added in order to overcome the previous stream version's scalefactors range deficiency. In SV8 the limitation is gone and no internal clipping occurs.
seed, can you explain what means 'no internal clipping'?
is this the solution to the karma all lossy codecs face - and the reason we use MP3Gain, for instance?
As far as I know, MP3Gain's purpose is to apply values which allow to losslessly normalize the music's volume and make all tracks sound equally loud. This is not the same as --xlevel which was a hack added in order to overcome the previous stream version's scalefactors range deficiency. In SV8 the limitation is gone and no internal clipping occurs.
A loud CD will always reach the full scale
but it will stop at 0.0dB (a.k.a 1.0) no matter how clipped the CD is.
Lossy encoders
introduce quantitization errors that will make the music to go over the full scale limits (example album peak 1.1600)
aggravating the situation upon decoding.
MP3Gain is also the tool to
minimize that effect, by normalizing the peaks.
What you say does it mean that a encoded
MPC file won't go over 0.0dB limit with clip-pressed music?
I'm wondering when I should take the jump to convert my approx 260GB of musepack files to SV8? Doesn't help that I'm still using FB2K 0.8.3 on my main machine!
Thanks Seed! I remember donating to Frank's PC fund in the hopes that SV8 would emerge. And here it is!
Congratulations, MPC team. Musepack is still my lossy format of choice, and whenever I have a friend who is technically-competent enough, it's what I use for sharing tunes.
Wow, MPC rises from the "darkness" ...
Doesn't help that I'm still using FB2K 0.8.3 on my main machine!
Same here.
Lossy encoders introduce quantitization errors that will make the music to go over the full scale limits (example album peak 1.1600) aggravating the situation upon decoding.
MP3Gain is also the tool to minimize that effect, by normalizing the peaks.
Side effects are never a reason to use a thing. At much, are a reason to NOT use a thing.
In fact, MP3Gain per se doesn't solve possible clipping, and that's why players add *also* an option of "clipping prevention" with replaygain (because it can know its highest peak, and preadjust the volume so that it keeps under 0.0dB).
What you say does it mean that a encoded MPC file won't go over 0.0dB limit with clip-pressed music?
I really wonder why all the savvy MPC users don't tell you this. MPC SV7 had a design limitation in which encoding highly compressed music ( i.e. nowaday's CD music ), could reach a limit in its values to store, and as such, cause an artifact in those places.
When this was discovered, the parameter --xlevel was added in order to prevent the artifact from happening. I can't comment on how it did so (lowering the volume, doing hard clip on the value instead of letting it overflow...)
So no. It does not solve what you're talking about, and it still does have that problem. It just doesn't have its own bug, with the need of its own patch.
thanks [JAZ] for explaining that...
' date='Sep 25 2007, 19:02' post='518982']
When this was discovered, the parameter --xlevel was added in order to prevent the artifact from happening. I can't comment on how it did so (lowering the volume, doing hard clip on the value instead of letting it overflow...)
It used a trick to represent it in the bitstream which isn't understood by (very) old decoders. The values where still stored correctly. Unless the --xlevel trick wasn't enough (in which case the encoder would warn).
Is there any way to batch convert from SV7 to SV8? BTW, using * in output name results in a crash.
Is there any way to batch convert from SV7 to SV8? BTW, using * in output name results in a crash.
just in case, devs recommended not to use it just yet, for normal use.
Phreakin awesome!
Musepack <3
I wonder what Andre Buschmann is doing nowadays
Keep up the good work
Congrats! This is really great to see. It must have been already way back in 2002 that people were talking about this SV8 thing . It's nice to know that Musepack is still being developed. I still have about 300 records in --insane.
I will repeat my findings with mpcdec.
mpcdec doesn't decode to stdout but writes to the file: -
mpcdec test.mpc - | …
Is decoding to stdout not implemented yet?
According to the timeline (http://trac.musepack.net/trac/timeline), pipe decoding was implemented on 27th September, however the link to the windows package still points to the one from 23th September.
Maybe somebody can compile the latest source?
Been searching the forums for the old high bitrate listening tests. Granted, Vorbis and LAME have improved since then. Does anybody have a link to a more recent test than this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=23355)?
Been searching the forums for the old high bitrate listening tests. Granted, Vorbis and LAME have improved since then. Does anybody have a link to a more recent test than this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=23355)?
This one (http://www.hydrogenaudio.org/forums/index.php?showtopic=36465), a year later.
Been searching the forums for the old high bitrate listening tests. Granted, Vorbis and LAME have improved since then. Does anybody have a link to a more recent test than this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=23355)?
This one (http://www.hydrogenaudio.org/forums/index.php?showtopic=36465), a year later.
Thanks. That's the one I last remembered reading, but couldn't find it.
Fantastic news.
I knew this day would come...the "eternal awaited" SV8
Been searching the forums for the old high bitrate listening tests. Granted, Vorbis and LAME have improved since then. Does anybody have a link to a more recent test than this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=23355)?
This one (http://www.hydrogenaudio.org/forums/index.php?showtopic=36465), a year later.
Thanks. That's the one I last remembered reading, but couldn't find it.
More proof that has failed to quench the seemingly widely held belief that "MPC is the most transparent lossy format at 160 kbps and above" unfortunately. Calling them anything other than equal would be disingenuous, IMO.
Been searching the forums for the old high bitrate listening tests. Granted, Vorbis and LAME have improved since then. Does anybody have a link to a more recent test than this one (http://www.hydrogenaudio.org/forums/index.php?showtopic=23355)?
This one (http://www.hydrogenaudio.org/forums/index.php?showtopic=36465), a year later.
Thanks. That's the one I last remembered reading, but couldn't find it.
More proof that has failed to quench the seemingly widely held belief that "MPC is the most transparent lossy format at 160 kbps and above" unfortunately. Calling them anything other than equal would be disingenuous, IMO.
I don't think anybody is claiming MPC superiority anymore. At least, not in this forum. If they are, I haven't seen it.
I don't think anybody is claiming MPC superiority anymore. At least, not in this forum. If they are, I haven't seen it.
http://www.hydrogenaudio.org/forums/index....st&p=518844 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=57717&view=findpost&p=518844)
http://www.hydrogenaudio.org/forums/index....mp;#entry516550 (http://www.hydrogenaudio.org/forums/index.php?showtopic=57514&st=0&p=516550&#entry516550)
I don't think anybody is claiming MPC superiority anymore. At least, not in this forum. If they are, I haven't seen it.
http://www.hydrogenaudio.org/forums/index....st&p=518844 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=57717&view=findpost&p=518844)
http://www.hydrogenaudio.org/forums/index....mp;#entry516550 (http://www.hydrogenaudio.org/forums/index.php?showtopic=57514&st=0&p=516550&#entry516550)
In the first thread you linked I didn't see anyone claim MPC superiority, only one person joking about "bowing down to MPC". In the 2nd, I saw one poster who claimed it was better than MP3.
In the first thread you linked I didn't see anyone claim MPC superiority. In the 2nd, I saw one poster who claimed it was better than MP3.
Now bowdown to MPC! (Well, I thought it funny at least. It was posted shortly after he finished with the other thread.)
You need to read through the other one to see that he also suggests that MPC is superior to AAC and seems to prefer it over OGG as well.
In the first thread you linked I didn't see anyone claim MPC superiority. In the 2nd, I saw one poster who claimed it was better than MP3.
Now bowdown to MPC! (Well, I thought it funny at least. It was posted shortly after he finished with the other thread.)
You need to read through the other one to see that he also suggests that MPC is superior to AAC and seems to prefer it over OGG as well.
Yeah, I didn't see the the Ogg part. Oh well... Most of us know
He's ok with ogg's quality, just that mpc was better for his purposes.
Anyhow, I thought it was funny. Sorry for going off-topic.
Just curious how the beta is doing. Would like to see this out of beta, and support in Rockbox for the new stream version.
there has been some upstream dev since the beta to address some of the issues brought up here like:
* piped i/o for mpcdec
* fix for id3v2 seek bug
* mpc2sv8 output options (overwrite with -o and to directory)
* quantizer change (also helps in rockbox integration)
and preglow will be working on the rockbox changes when he is able.
later
Great news, thanks for the update.
there has been some upstream dev since the beta to address some of the issues brought up here like:
* piped i/o for mpcdec
* fix for id3v2 seek bug
* mpc2sv8 output options (overwrite with -o and to directory)
* quantizer change (also helps in rockbox integration)
and preglow will be working on the rockbox changes when he is able.
later
Nice work.
Are there win32 compiles of these updates available?
If so I will do some testing with the pipe output of mpcdec.
no - but the windows project files are updated so you can checkout and compile at a whim!
later
wow, I never thought I would see the day sv8 came out! time for another listening test guru?
There are no changes to psychoacoustic model, as stated. So, no tests needed, at least for now.
heh, yeah I just read that, but you replied before I could edit my post
there has been some upstream dev since the beta to address some of the issues brought up here like:
* piped i/o for mpcdec
* fix for id3v2 seek bug
* mpc2sv8 output options (overwrite with -o and to directory)
* quantizer change (also helps in rockbox integration)
and preglow will be working on the rockbox changes when he is able.
later
Decode to stdout still not working with the latest binaries.
Is there a special command for stdout or can I use - ?
http://r2d.musepack.net/files/musepack_bin_20071123.zip (http://r2d.musepack.net/files/musepack_bin_20071123.zip)
Decode to stdout still not working with the latest binaries.
Is there a special command for stdout or can I use - ?
http://r2d.musepack.net/files/musepack_bin_20071123.zip (http://r2d.musepack.net/files/musepack_bin_20071123.zip)
It works fine for me. Yes, you should use - for stdout.
D:\Util\MusePack\sv8>mpcdec.exe -h
mpcdec - Musepack (MPC) decoder v0.9.2 (C) 2006-2007 MDT
Built Nov 23 2007 16:27:47
Usage: mpcdec.exe [-i] [-h] <infile.mpc> [<outfile.wav>]
-i : print file information on stdout
-c : check the file for stream errors
(doesn't fully decode, outfile will be ignored)
-h : print this help
you can use stdin and stdout as resp. <infile.mpc> and
<outfile.wav> replacing the file name by "-"
E:\Console\codec>mpcdec input.mpc - | lame -V5 --vbr-new --quiet - output.mp3
mpcdec - Musepack (MPC) decoder v0.9.2 (C) 2006-2007 MDT
Built Nov 23 2007 16:27:47
2446080 samples decoded in 342 ms (162.18x)
This wil create a mp3 file with very much noise.
Decoding directly to a wav file is working without any problem.
Also decoding without transcoding creates a wav file with very much noise.
E:\Console\codec>mpcdec input.mpc - > output.wav
mpcdec - Musepack (MPC) decoder v0.9.2 © 2006-2007 MDT
Built Nov 23 2007 16:27:47
2446080 samples decoded in 405 ms (136.95x)
stdout works for me on debian - both output to file and to pipe.
and since others on windows have verified this there must be something wrong with your situation specifically.
later
When trying decoding to stdout on another system it gave me the error message that msvcr71.dll was missing.
After copying msvcr71.dll to the same directory as mpcdec.exe it gives the same disturbed output as on my other computer.
PS
Decoding to file works perfectly on both systems.
E:\Console\codec>mpcdec input.mpc - | lame -V5 --vbr-new --quiet - output.mp3
mpcdec - Musepack (MPC) decoder v0.9.2 (C) 2006-2007 MDT
Built Nov 23 2007 16:27:47
2446080 samples decoded in 342 ms (162.18x)
This wil create a mp3 file with very much noise.
Now I see.
Verified here with 3 versions of lame as well as with Ogg Vorbis. Same results (noise).
~
I haven't looked at it yet and might do it later this evening, but what's the output format of mpcdec when writing to stdout? wave or raw pcm? What LAME version are you using?
Ok, seems a simple mpcdec x.mpc - >x.wav results in noise too. Maybe some line ending translation is going on here? (LF -> CR-LF)
Another small issue: the mpcenc seems to disturb my console color setting. (http://home.arcor.de/rhegemann/cmd-box.png)
Years of wait... thanks, now it nearly dream will be ture...
( missing Hydrogenaudio.. )
i just noticed - r2d fixed the stdin/out for y'all windows folks in SVN.
later
i just noticed - r2d fixed the stdin/out for y'all windows folks in SVN.
later
Confirmed
mpcdec (build 20071201) (http://ant0nski.hit.bg/musepack/20071201/mpcdec.7z)
~
i just noticed - r2d fixed the stdin/out for y'all windows folks in SVN.
later
Confirmed
mpcdec (build 20071201) (http://ant0nski.hit.bg/musepack/20071201/mpcdec.7z)
~
Thanks for the updated binaries.
The first tests are looking promising.
Also the terminate bug (link below) from the previous 1.95e decode is fixed.
http://www.hydrogenaudio.org/forums/index....showtopic=54889 (http://www.hydrogenaudio.org/forums/index.php?showtopic=54889)