The Musepack SV8 beta is out.

To quote from the official musepack.net forum post:

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


Download:

Windows package
Source code


To test SV8 files, you can use the newly released foobar2000 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?