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

--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 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 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.


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?

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: -


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.

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.

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/changelog.html

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!


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?

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.

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" ...

Same here.

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).



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...

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.