Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: SV8 wishes (Read 11677 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

SV8 wishes

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

SV8 wishes

Reply #1
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.

SV8 wishes

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

SV8 wishes

Reply #3
r2d,

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

SV8 wishes

Reply #4
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

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


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.

 

SV8 wishes

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

Keep improving sound quality.

Thanks!

SV8 wishes

Reply #6
I can see it now
Code: [Select]
Change log for MPC SV8:
*Updated version number of encoder to SV8 to reflect encoder version
[span style=\'font-size:8pt;line-height:100%\']"We will restore chaos"-Bush on Iraq[/span]


SV8 wishes

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


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.
It's a 'Jump to Conclusions Mat'. You see, you have this mat, with different CONCLUSIONS written on it that you could JUMP TO.

SV8 wishes

Reply #9
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.

SV8 wishes

Reply #10
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?

SV8 wishes

Reply #11
r2d - thanks for the updates. Do you have any idea of how much the filesize will increase for files transcoded from sv7?

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

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?

Yes, if results are good enough to justify it.

SV8 wishes

Reply #12
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
In theory, there is no difference between theory and practice. In practice there is.

SV8 wishes

Reply #13
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

SV8 wishes

Reply #14
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.
In theory, there is no difference between theory and practice. In practice there is.