mppenc 1.15u is out.
It now properly handles the samples provided in this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=18211), even at 'standard' quality. In addition, teh01.flac/teh02.flac (http://files.musepack.net/samples/) can be encoded gaplessly now. There are a few more known cases that fail older versions of the encoder and other codecs too. 1.15u is a fix for them all.
The code has changed in the way the encoded signal is padded to MPC frame boundaries. The beginning and end of track encoding is handled differently now. Thanks a lot to Xiph's Monty for the initial advice.
We're back with MSVC for the Windows compile. The file is now static-linked to avoid issues for all users.
mppenc 1.15u for Windows (http://www.musepack.net/index.php?pg=win)
mppenc 1.15u for Linux (http://www.musepack.net/index.php?pg=lin)
mppenc 1.15u source (http://www.musepack.net/index.php?pg=src)
Don't forget that our SVN server (http://svn.musepack.net/websvn/) is always ready for new submissions. You can usually find anything we work on there.
Sweet. The best encoder just got better. The release cycle of mppenc versions got quite shorter than before.
After 1.15 branch becomes beta (or stable), is the team planning to take on SV8? Is there any current development in SV8 branch?
cool, it resolve the gapless problem i have in 1.15t (blop between some track with continuous sound with 1.15t but not in 1.14)
After 1.15 branch becomes beta (or stable), is the team planning to take on SV8? Is there any current development in SV8 branch?
[a href="index.php?act=findpost&pid=277035"][{POST_SNAPBACK}][/a]
Odd numbered releases are always alpha. 1.16 is, I believe, planned to be the final SV7 encoder. AFAIK they, and we, are still waiting on Mr. Klemm for SV7.5/8 releases . . . . or has the team decide to try without his help?
We'll direct all of our efforts toward SV8 soon (hopefully). It's gonna be a mighty task, but I hope we'll find more capable coders to help us. Right now we're spending 100% of our time hunting for more samples that 1.15u might fail with. Eventually, we'll reach 1.16 and then, hopefully, with the help of Frank, we'll try to make SV8 a reality. No promises, though.
mppenc 1.15u is out.
Great!
It looks like musepack is being most actively developed recently in comparison to other codecs.
Keep up the great work!
This is the first real quality-related fix we've made without Frank's help. We'll work around the clock finding and fixing more bugs, but we'll need the help of the community. We want to see more high-bitrate ABX tests and more offers to help us code. Anyone who has experience with psymodels is very welcome. Frank is still an option, but we cannot and will not depend on his help. When he does help we consider it a bonus. We correspond with him often and he offers useful advice and listens to the samples I send him, but I'm sure his work prevents him from spending time coding, so it's basically us and anyone who's willing to help.
Enjoy the new encoder
I'd be happy to donate to mpc development. It's a good idea to keep a donation link at the Musepack site (http://www.musepack.net/) (PayPal, eGold, etc.) for people like me. Considering the amount of people only in HA that prefer MPC, this could enable the developers get nicer equipment, etc.
We only need your time and dedication. We will not accept any donations at any stage and our site/forum will always be free of ads. We really just want your help. Hunt for the link to our IRC channel on the main Musepack site and come visit us and show your support. We don't ask for anything else
Great news, thanks seed
I'm loving the development these days. The lossy scene has been really dead the past year so it's good to see some progress, and with MPC being my favorite lossy codec, this news is the best!
Freaking awesome! MPC development team rules! :D
The lossy scene has been really dead the past year . .
[a href="index.php?act=findpost&pid=277129"][{POST_SNAPBACK}][/a]
Vorbis 1.1 (+aoTuV betas)
LAME 3.96.1 (+getting close to LAME4 betas)
Nero AAC (big improvements + PS on the horizon)
I don't see how the lossy scene has been dead at all . . . . In fact I think its been more active then the
lossless scene with the exception of WavPack 4.
edit: Thanks for updating us on the status of the MPC Development team Seed! I can't help at all with the coding, but maybe I'll take a few more cracks at ABXing MPC. Last time I tried I couldn't get anywhere with it at all which is the main reason it has been my lossy codec of choice.
edit: changed lossy to lossless
I don't see how the lossy scene has been dead at all . . . . In fact I think its been more active then the lossy scene with the exception of WavPack 4.
[a href="index.php?act=findpost&pid=277181"][{POST_SNAPBACK}][/a]
Yes. Lossy scene gets more active recently and I'm excited.
mppenc 1.15u is out.
Great work..
Many thanks to all musepack developers for the constant development, interest and dedication.
Oh, yeah... This codec is really making progress.. THANKS, dear devs
By the way, what will the SV8 give us comparing to SV7 ? Sorry if it is mentioned
somewhere, I couldn't find...
Great work !
Just a thing, I think the 1.15u mppenc & mppdec still say v1.15t.
By the way, what will the SV8 give us comparing to SV7 ? Sorry if it is mentioned
somewhere, I couldn't find...
[a href="index.php?act=findpost&pid=277351"][{POST_SNAPBACK}][/a]
Personally, I'd like to use musepack also as audio in video files. AFAIK that won't be possible until SV8 comes (for some reason that I don't know).
Great work !
Just a thing, I think the 1.15u mppenc & mppdec still say v1.15t.
[a href="index.php?act=findpost&pid=277794"][{POST_SNAPBACK}][/a]
Where? The decoder hasn't changed anyway...
Who is MDI?
Great work !
Just a thing, I think the 1.15u mppenc & mppdec still say v1.15t.
[a href="index.php?act=findpost&pid=277794"][{POST_SNAPBACK}][/a]
> sed -i 's:15t:15u:' <path>/sv7/version
Who is MDI?
MDI might be Management Development Institute
MDT is Musepack Development Team. After the first quality-related change the team made to the encoder, there was a need for a name to be added to the credits. Since none of the programmers wanted to take the credit for themselves, we type Musepack Development Team, or in short, MDT.
It is amazingly encouraging to see development picking up again. I hope at some point to be able to use mpc on portables and at some point in the future would like to see a -portable setting with focus on balance of size/quality/battery life, since mpc already uses less power then other codecs focusing on this may make it ideal, not to mention its high quality.
Great work !
Just a thing, I think the 1.15u mppenc & mppdec still say v1.15t.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=277794")
> sed -i 's:15t:15u:' <path>/sv7/version
[a href="index.php?act=findpost&pid=277850"][{POST_SNAPBACK}][/a]
Will add this to the gentoo ebuild
[a href="http://bugs.gentoo.org/show_bug.cgi?id=83528]Gentoo Linux ebuild for musepack-tools 1.15u[/url]
It is amazingly encouraging to see development picking up again. I hope at some point to be able to use mpc on portables and at some point in the future would like to see a -portable setting with focus on balance of size/quality/battery life, since mpc already uses less power then other codecs focusing on this may make it ideal, not to mention its high quality.
[a href="index.php?act=findpost&pid=277995"][{POST_SNAPBACK}][/a]
You can already use it on Windows Mobile smartphones using betaplayer. I load up my phone with 4-5 new albums a day to listen to at work, and don't have to transcode them from mpc to anything...
It is amazingly encouraging to see development picking up again. I hope at some point to be able to use mpc on portables and at some point in the future would like to see a -portable setting with focus on balance of size/quality/battery life, since mpc already uses less power then other codecs focusing on this may make it ideal, not to mention its high quality.
[a href="index.php?act=findpost&pid=277995"][{POST_SNAPBACK}][/a]
Quality setting 4 is pretty damn good already. See Roberto's tests.
Posted this on Musepack.net already, but there's probably more traffic here ...
Thanks to the developers who are continuing the progress of Musepack.
Quick request: does anyone out there have a mirror of the latest Win version? My work firewall won't let me access the main download site.
Thanks!
Quick request: does anyone out there have a mirror of the latest Win version? My work firewall won't let me access the main download site.
Thanks!
[a href="index.php?act=findpost&pid=278596"][{POST_SNAPBACK}][/a]
(removed, newer version available now)
Thanks B!
It is amazingly encouraging to see development picking up again. I hope at some point to be able to use mpc on portables and at some point in the future would like to see a -portable setting with focus on balance of size/quality/battery life, since mpc already uses less power then other codecs focusing on this may make it ideal, not to mention its high quality.
[a href="index.php?act=findpost&pid=277995"][{POST_SNAPBACK}][/a]
Quality setting 4 is pretty damn good already. See Roberto's tests.
[a href="index.php?act=findpost&pid=278158"][{POST_SNAPBACK}][/a]
Agreed, but as little intentional tuning has gone into low bitrates for MPC there is probably some room for improvement. In addition, I dont know if it would be possible to NOT use some coding tricks that might save even more on battery power. All academic as there is little to no support right now (betaplayer on pocketpc - come on palm) and dev is just picking up on what many ppl wrote off as a dead codec
Yes, very nice indeed!
I encoded some non-problem samples just to check if avg bitrate changed and was positively surprised to see the difference was just a few bytes. In prior tunings the solving of problem samples made bitrate encrease even for non-problem (and already transparent) samples, which was suboptimal IMHO.
I see differences in binary size and I have noticed a ~6% speedup in encoding compared to 1.15t. Were different compiler settings used?
1.15t was just an attempt to solve a problem by using a different compiler. It was not the right solution, although it did eliminate the glitches in teh_sample. 1.15u is made by MSVC and the compiler was set to optimize for speed, not binary size. It should now create MPCs that are indeed similar to the ones 1.15r created (Frank's last version) except for the samples that trigger the gapless bug or the other 2 bugs discovered and fixed in 1.15s.
This is the first real quality-related fix we've made without Frank's help.
Enjoy the new encoder
[a href="index.php?act=findpost&pid=277061"][{POST_SNAPBACK}][/a]
OK, tnks a lot!
But!
Can you explain me, why if it yours first release without Frank, why it size ~ 100Kb, but 1.15t was only ~ 50Kb, though, 1.14 ~ 75Kb??????
So! What are you completely lost (50Kb!!!) in 1.15t when compile it, and what is it apears now in 1.15u again????
1.15t was just an attempt to solve a problem by using a different compiler.
OK!
Forgot to read to the end...
Can you explain me, why if it yours first release without Frank, why it size ~ 100Kb, but 1.15t was only ~ 50Kb, though, 1.14 ~ 75Kb??????
So! What are you completely lost (50Kb!!!) in 1.15t when compile it, and what is it apears now in 1.15u again???
I just compiled mppenc 1.15u for Mac OS X and it came out as a 308KB executable (192KB after I strip it).
I dont care much about filesizes, but its strange that it varies so much!
Can you explain me, why if it yours first release without Frank, why it size ~ 100Kb, but 1.15t was only ~ 50Kb, though, 1.14 ~ 75Kb??????
So! What are you completely lost (50Kb!!!) in 1.15t when compile it, and what is it apears now in 1.15u again????
[a href="index.php?act=findpost&pid=281552"][{POST_SNAPBACK}][/a]
Un-upx them all and i'm pretty sure, you'll get almost everything back (at least in filesize part)