Hello,

SV8 is on it's way. One target of the first SV8 release is lossless conversion from SV7 files, so there will be limited changes in the compression engine.
You can see the current SV8 schedule of conditions ( http://trac.musepack.net/trac/wiki/SV8ScheduleOfConditions ) in the Musepack Trac Wiki. I'm waiting for your wishes / comments / improvement suggestions on this stream.

Thanks

Independent frames or at least groups of frames, optional or recreatable file header. So that Musepack streams could be cut and played back like MPEG Layer-3. It is important for a lossy format to enable at least basic lossless transformations.

Most of all I'm hoping for an active development...

r2d,

are you an mpc developer? Could you tell us if there is someone working on it at the moment?

Yes, I am since september. See http://trac.musepack.net/trac/timeline



Frames are grouped in blocks. You can cut at block boundaries and an optional edition block allow to skip samples at the begining and the end of the stream. See http://trac.musepack.net/trac/wiki/SV8ScheduleOfConditions.

Mac (PPC) encoder, decoder and translator support. Mac playback.

Keep improving sound quality.

Thanks!

I can see it now

You could try ffmpeg or mplayer, to playback mpc or decoding on mac

I fixed compilation for sparc64 recently in mppenc 1.16+svn, so the encoder will work with any mac (ppc or x86). The decoder has been compatible since the beginning.
What do you mean by 'translator' btw ?
What would be nice is a quicktime plugin, which will happen only with a mac developer :|

Btw, there is already a rough version of sv8 in svn, it compiles, it decodes with xmms/winamp, it has new huffman code (~+2% compression), new bitstream (which also allow mp4/mkv/nut/whatever). That's why r2d is trying to get useful feedback while the new code is still in progress, so people have a chance to interact.

I'd glad to see if SV8 can improve quality of classical music. There's some defect been discovered via listening test by Guruboolez, which really should be given enough respect for developers IMHO.

Can we keep out the off-topic complaining? I use mpc because it's had a pretty stable format (althought with intra-frame dependencies) for years. I don't need to use unofficial builds, it's fast, and just works. You might find codecs with better scores in some of the metrics, but mpc is competitive *to me* in pretty much all of them. So why change?

r2d - thanks for the updates. Do you have any idea of how much the filesize will increase for files transcoded from sv7? And when you say the quality will increase after sv8 - does this mean there will be bitstream format changes both in the decoder and encoder later?

The file size should decrease when transcoding from sv7 to sv8 (even if a seek table has been added) by ~2%.


Yes, if results are good enough to justify it.

I remember there was this "overloading" (of scalefactor?) thing that was more or less "solved" with --xlevel.
This was one of the things that was supposed to be definitively fixed in SV8

It's fixed, just no yet removed the --xlevel switch

Another thing, that I think was once suggested for SV8, is more a Stream header/info thing.
Store (somewhere) the encoding quality setting numerical including the decimals. So instead of the old "Standard" "Xtreme" "Insane", the value of --quality e.g. 5.48.