Musepack.net forum thread
A new mppenc version is out. It includes some small fixes and changes.
mppenc 1.15s (Windows)
mppenc 1.15s (Linux)
Fixes from 1.15r:
1. In some rare cases, the output file would have an incorrect duration (4 missing samples) when encoding some very long tracks.
2. There was a glitch at the end of the track when encoding from a 24-bit source through pipes.
Misc changes:
1. --xlevel is now used by default. Use --noxlevel to override (--longhelp shows the full command-line options).
2. Removed "Unstable/Experimental" flag writing. The encoder now stores the profile info like all stable versions do.
The new version has been tested on these CPUs: AMD K6-2, AMD Thunderbird, AMD Athlon XP1700+, Athlon 64, and a Pentium 4.
The new source can be found here
Full Version: Musepack encoder 1.15s released
Finally!
Has Frank been involved in the development of this new version?
Excellent news. Thank you Flank Klemm.
EDIT:
Maybe not Frank then, which is a pity tbh. Still a much needed release, kudos to the developers.
EDIT:
Maybe not Frank then, which is a pity tbh. Still a much needed release, kudos to the developers.
QUOTE
Has Frank been involved in the development of this new version?
No, we tied him to his desk at work, went to his house, sat near his new computer, and started coding.
This is just a maintenance release made by the development team. The goal was to clean some of the code just to allow an easier job for Frank if he chooses to release SV7.5. If 1.15x is the last SV7 version ever, we'll do everything to make sure it's damn stable and usable.
Is 1.15 the new officially recommanded version now?
well, it just replaces 1.15r as 1.15s is a community bug-fix release
many still use 1.14 because klemm didn't put as much time into testing 1.15 before he went afk
later
many still use 1.14 because klemm didn't put as much time into testing 1.15 before he went afk
later
Oh well thats a little disappointing. I guess I rushed to conclusions when I saw the news. Oh well, at least its something.
In v1.14 beta is still a bug included. The tagging-engine in it destroys the MPC-file (even the encoder itself crashes sometimes) if there are german special characters ("umlaute" like (ä,ü,ö), but also spanish letters with accents like è or á in the original tag when doing a transcode from a lossless source (like APE or FLAC).
Maybe one of these developers could ask Frank for the source of 1.14 b, so that this little bug could be fixed. It would be important, ´cause 1.14 beta still is and will be the most-used version of all mpc-versions for now and also the next future for sure.
Note: I just checked it out... That bug doesn´t appear anymore in the 1.15s.
Maybe one of these developers could ask Frank for the source of 1.14 b, so that this little bug could be fixed. It would be important, ´cause 1.14 beta still is and will be the most-used version of all mpc-versions for now and also the next future for sure.
Note: I just checked it out... That bug doesn´t appear anymore in the 1.15s.
QUOTE(Zurman @ Nov 24 2004, 12:29 AM)
Is 1.15 the new officially recommended version now?
Sure not, because it´s still in alpha-status.
QUOTE(R.A.F. @ Nov 23 2004, 09:25 PM)
Sure not, because it´s still in alpha-status.
mppenc 1.15r has been sufficiently field-tested to qualify as officially recommendable.
This new version, with the removal of the "Experimental" tag, seems to imply that it is the new recommended version.
There seem to be no reasons to stick with 1.14 other than paranoia.
1.15s output is identical to 1.15r (do an inverse mix-paste) when the bugfix isn't triggered, so there's no degradation in quality here. Encoding speed is the same. Seeing that there are very rare cases of audible artefacts for both 1.14 and 1.15r/s at standard quality, i think 1.15s is about as safe to use as 1.14 now. Pretty damn safe, that is.
P.S. Thanks for the work, guys.
P.S. Thanks for the work, guys.
QUOTE(CiTay @ Nov 24 2004, 02:59 PM)
1.15s output is identical to 1.15r (do an inverse mix-paste)
Didn't mean to imply otherwise, although I see how my wording could be misinterpreted.
Like CiTay said, good work MPC team!
*heads off to update his mppenc binary*
QUOTE(R.A.F. @ Nov 24 2004, 06:25 AM)
QUOTE(Zurman @ Nov 24 2004, 12:29 AM)
Is 1.15 the new officially recommended version now?
Sure not, because it´s still in alpha-status.
Eh? mppenc alpha status is sort of arbitrary at the moment, since this version (1.15r) has been field-tested for almost two years and known issues are axed now*. Couldn't agree more with Canar, only reason to not use it is paranoia.
*: The necessary changes were rather minute, so it can be said for sure that nothing was broken from 1.15s, so theoretically the new version is just as well tested as 1.15r
I used to use 1.14 because I hated the alpha/experimental tag. No more. Thank you!
Thank you!
Good stuff
I'm updating the gentoo ebuild for musepack-tools, and I'm having trouble with this line in wave_out.c:
#include <audio.h>
Where is this audio.h supposed to be ? TIA
I'm updating the gentoo ebuild for musepack-tools, and I'm having trouble with this line in wave_out.c:
#include <audio.h>
Where is this audio.h supposed to be ? TIA
Well I've discovered something, albeit it isn't mppenc.exe related. mppenc.exe wasn't packed/compressed with the current stable version of UPX v1.25.
On the UPX page http://upx.sourceforge.net/#unstable what is quoted below is a direct quote:
On the UPX page http://upx.sourceforge.net/#unstable what is quoted below is a direct quote:
QUOTE
All versions 1.1x and 1.9x are unstable beta releases - use them only for testing, and never distribute a program that is packed with them! There are known bugs.
QUOTE(NumLOCK @ Nov 25 2004, 12:48 PM)
Good stuff
I'm updating the gentoo ebuild for musepack-tools, and I'm having trouble with this line in wave_out.c:
#include <audio.h>
Where is this audio.h supposed to be ? TIA
I'm updating the gentoo ebuild for musepack-tools, and I'm having trouble with this line in wave_out.c:
#include <audio.h>
Where is this audio.h supposed to be ? TIA
Random guess.
It may be due to the ESD dependency (Enlightened Sound Daemon, the old and deprecated gnome sound server).
QUOTE(Andavari)
Well I've discovered something, albeit it isn't mppenc.exe related. mppenc.exe wasn't packed/compressed with the current stable version of UPX v1.25.
It'll be replaced today. 1.92b has been very stable on all binaries I've compressed and sent to others, but 1.25 should indeed be used for this.
QUOTE(Lefungus @ Nov 25 2004, 02:02 PM)
QUOTE(NumLOCK @ Nov 25 2004, 12:48 PM)
Good stuff
I'm updating the gentoo ebuild for musepack-tools, and I'm having trouble with this line in wave_out.c:
#include <audio.h>
Where is this audio.h supposed to be ? TIA
I'm updating the gentoo ebuild for musepack-tools, and I'm having trouble with this line in wave_out.c:
#include <audio.h>
Where is this audio.h supposed to be ? TIA
Random guess.
It may be due to the ESD dependency (Enlightened Sound Daemon, the old and deprecated gnome sound server).
Correct. It was due to the IRIX sound #define which was present. Case closed, I fixed it from the gentoo ebuild
Standalone build (ie: just typing make) works fine. So nothing is buggy
wave_out.c is for mppdec
for 1.15r/s focus would only be on encoder since the decoder is already superceded by 1.95(x) and libmusepack
to build on linux (gcc3) you'll want a few changes to the Makefile (these are the minimal changes):
15,16c19,20
< CC = cc -pipe -L/lib
< CC3 = gcc3 -pipe -L/lib
---
> CC = gcc -pipe -L/lib
> CC3 = gcc -pipe -L/lib
146,147c150
< -mpreferred-stack-boundary=2 -malign-jumps=5 -malign-loops=0 -malign-functions=5
<
---
> -mpreferred-stack-boundary=2 -falign-jumps=5 -falign-loops=0 -falign-functions=5
159c162
< -mpreferred-stack-boundary=2 -malign-jumps=5 -malign-loops=0 -malign-functions=5
---
> -mpreferred-stack-boundary=2 -falign-jumps=5 -falign-loops=0 -falign-functions=5
220c223
< ALL_TARGETS = $(MPPDEC_TARGET) $(MPPENC_TARGET) $(STREAM_TARGET) $(REPLAY_TARGET) $(CLIPSTAT_TARGET) $(TAGGER_TARGET)
---
> ALL_TARGETS = $(MPPENC_TARGET)
these changes are already present in the musepack.net binaries
1.15s linux dev goodies can be found here : download or browse
later
for 1.15r/s focus would only be on encoder since the decoder is already superceded by 1.95(x) and libmusepack
to build on linux (gcc3) you'll want a few changes to the Makefile (these are the minimal changes):
CODE
15,16c19,20
< CC = cc -pipe -L/lib
< CC3 = gcc3 -pipe -L/lib
---
> CC = gcc -pipe -L/lib
> CC3 = gcc -pipe -L/lib
146,147c150
< -mpreferred-stack-boundary=2 -malign-jumps=5 -malign-loops=0 -malign-functions=5
<
---
> -mpreferred-stack-boundary=2 -falign-jumps=5 -falign-loops=0 -falign-functions=5
159c162
< -mpreferred-stack-boundary=2 -malign-jumps=5 -malign-loops=0 -malign-functions=5
---
> -mpreferred-stack-boundary=2 -falign-jumps=5 -falign-loops=0 -falign-functions=5
220c223
< ALL_TARGETS = $(MPPDEC_TARGET) $(MPPENC_TARGET) $(STREAM_TARGET) $(REPLAY_TARGET) $(CLIPSTAT_TARGET) $(TAGGER_TARGET)
---
> ALL_TARGETS = $(MPPENC_TARGET)
these changes are already present in the musepack.net binaries
1.15s linux dev goodies can be found here : download or browse
later
Seems like profile bit is missed in sources?
It still shows 'Unstable/Experimental' (when built from source that is, binary works fine).
It still shows 'Unstable/Experimental' (when built from source that is, binary works fine).
for profiles, change these lines in encode_sv7.c
70a71
> #if 0
73c74,75
< else
---
> else
> #endif
those who want to compile on linux download the dev pack in my previous post
70a71
> #if 0
73c74,75
< else
---
> else
> #endif
those who want to compile on linux download the dev pack in my previous post
I'll try it, thanks.
Just a note for those interested, a gentoo ebuild I updated for 1.15s can be found in bugs.gentoo.org
hmm... where's the binary? 
QUOTE(vasya_pupkin @ Nov 27 2004, 05:33 PM)
hmm... where's the binary?
In a hidden box behind your toolshed.
QUOTE(zZzZzZz @ Nov 23 2004, 05:57 PM)
A new mppenc version is out. It includes some small fixes and changes.
mppenc 1.15s (Windows)
mppenc 1.15s (Linux, static)
mppenc 1.15s (Linux, dynamic)
mppenc 1.15s (Windows)
mppenc 1.15s (Linux, static)
mppenc 1.15s (Linux, dynamic)
Ok, link is just broken. Found binary on musepack.net
This is a great news for sure
Now when we try to encode it,can we expect it to be faster couse xlevel is hardcoded?I am just curius as mpc is my codec of choice
EDIT;jUST TESTED 1.14B and 1.15s on 1 file;metal band(wasp)and the encoding time was same-13-14 seconds on all 4 testings,Song lenght was3.06.
Now when we try to encode it,can we expect it to be faster couse xlevel is hardcoded?I am just curius as mpc is my codec of choice
EDIT;jUST TESTED 1.14B and 1.15s on 1 file;metal band(wasp)and the encoding time was same-13-14 seconds on all 4 testings,Song lenght was3.06.
QUOTE(zver @ Nov 27 2004, 03:54 PM)
Now when we try to encode it,can we expect it to be faster couse xlevel is hardcoded?
I don't think so. I believe all they mean by hardcoded is enabled by default, all this should mean is that you don't need to add --xlevel to your command line. I don't see how that would increase the speed.
QUOTE(ssamadhi97 @ Nov 25 2004, 04:49 AM)
Eh? mppenc alpha status is sort of arbitrary at the moment, since this version (1.15r) has been field-tested for almost two years and known issues are axed now.
Sure. But shouldn't/couldn't this tag
QUOTE
MPC Encoder 1.15s --Alpha-- © 1992-2002 Buschmann/Klemm/Piecha
then be changed into
QUOTE
MPC Encoder 1.15s Beta © 1992-2002 Buschmann/Klemm/Piecha
?
Alpha, Beta.. Who cares? It now shows profile info, so no problems... Btw, it would be good to store all quality related settings used for encoding instead of just profile name, which is useless since --quality 5.5 (for example) is allowed And also version number is stored without letter.
It now shows profile info, so no problems... Btw, it would be good to store all quality related settings used for encoding instead of just profile name, which is useless since --quality 5.5 (for example) is allowed And also version number is stored without letter.
QUOTE(R.A.F. @ Nov 28 2004, 04:57 AM)
QUOTE(ssamadhi97 @ Nov 25 2004, 04:49 AM)
Eh? mppenc alpha status is sort of arbitrary at the moment, since this version (1.15r) has been field-tested for almost two years and known issues are axed now.
Sure. But shouldn't/couldn't this tag
QUOTE
MPC Encoder 1.15s --Alpha-- © 1992-2002 Buschmann/Klemm/Piecha
then be changed into
QUOTE
MPC Encoder 1.15s Beta © 1992-2002 Buschmann/Klemm/Piecha
?Nope, that's not possible. Of course the encoder could be changed to display this, but in mpc files the used encoder version is not saved in plain text, just a version number. And due to the numbering scheme itself, mpc decoders would still interpret this information as 1.15 --Alpha-- rather than Beta.
So on the whole it's not possible to "cleanly" change the status from alpha to beta without bumping the version number (to 1.16)
Anybody know where to find Mac OS X binaries?
I downloaded the source, but could not get it to compile...
I downloaded the source, but could not get it to compile...
http://www.rarewares.org/files/mpc/mpp-1.15r-MacOSX.tar.bz2
You can find it some other mpc stuff on rarewarez same as above link
You can find it some other mpc stuff on rarewarez same as above link
QUOTE(zver @ Dec 4 2004, 07:51 PM)
Thanks, but I was looking for the latest version.
Version 1.15s, not an old version dated 19.05.2004.
QUOTE(solaris @ Dec 4 2004, 11:14 AM)
Thanks, but I was looking for the latest version.
Version 1.15s, not an old version dated 19.05.2004.
Version 1.15s, not an old version dated 19.05.2004.
The latest "offical" (www.musepack.net) compile for Mac OS X is still at version 1.15r.
I came across a bunch of .mpc files with streamversion 7.1, whereas all my encoded files with 1.15s still say SV 7
Can anyone elaborate?
Can anyone elaborate?
SV7.1 is SV7 + PNS
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
Thanks Garf, it seems to kick in from below "Standard"
sorry if this is redundant, but I didn't follow the MPC news for a while.
Does this version show any improvements when playing back in foobar?
I did encode some CDs with 1.14 beta a year back or so, but seeking (10s forward/backwards etc.) was painfuly slow in foobar, so I replaced those encodes with standard lame mp3s over time.
the filesize, speed and quality of MPC was very appealing, but I skip a lot through the tracks while listening and just couldn't stand those ~0.5s pauses, while mp3 skips seamlessly
thanks for enlightenment
Does this version show any improvements when playing back in foobar?
I did encode some CDs with 1.14 beta a year back or so, but seeking (10s forward/backwards etc.) was painfuly slow in foobar, so I replaced those encodes with standard lame mp3s over time.
the filesize, speed and quality of MPC was very appealing, but I skip a lot through the tracks while listening and just couldn't stand those ~0.5s pauses, while mp3 skips seamlessly
thanks for enlightenment
QUOTE(jenz @ Dec 7 2004, 12:38 AM)
QUOTE(solaris @ Dec 4 2004, 11:14 AM)
Thanks, but I was looking for the latest version.
Version 1.15s, not an old version dated 19.05.2004.
Version 1.15s, not an old version dated 19.05.2004.
The latest "offical" (www.musepack.net) compile for Mac OS X is still at version 1.15r.
We should have 1.15s builds for the mac up shortly.
QUOTE(sony666 @ Dec 21 2004, 08:08 PM)
Does this version show any improvements when playing back in foobar?
I did encode some CDs with 1.14 beta a year back or so, but seeking (10s forward/backwards etc.) was painfuly slow in foobar, so I replaced those encodes with standard lame mp3s over time.
I did encode some CDs with 1.14 beta a year back or so, but seeking (10s forward/backwards etc.) was painfuly slow in foobar, so I replaced those encodes with standard lame mp3s over time.
This version just adds couple of small bugfixes and hardcoded --xlevel from 1.15r. IIRC seeking won't be properly fixed until SV 7.5 or SV 8, if these encoders will ever be created.
QUOTE(sony666 @ Dec 22 2004, 06:08 AM)
I did encode some CDs with 1.14 beta a year back or so, but seeking (10s forward/backwards etc.) was painfuly slow in foobar,
Seek time on Playback is mainly a decoder issue, see also this foobar topic. This encoder version will not make a difference in that respect.
QUOTE(Garf @ Dec 18 2004, 05:47 PM)
SV7.1 is SV7 + PNS
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
I can't find any info regarding this. Is a command line switch required to use it, or does it "kick in" automatically at low bitrates? I so, how low? Plus, are there any updates required to foobar on the playback/decoding side of things, or will it play MPC+PNS files properly as is? Thanks all!
QUOTE(Digisurfer @ Dec 22 2004, 05:06 PM)
I can't find any info regarding this. Is a command line switch required to use it, or does it "kick in" automatically at low bitrates? I so, how low? Plus, are there any updates required to foobar on the playback/decoding side of things, or will it play MPC+PNS files properly as is? Thanks all!
Ummm...
QUOTE(Mindaxiz @ Dec 19 2004, 07:51 AM)
Thanks Garf, it seems to kick in from below "Standard"
QUOTE(Digisurfer @ Dec 23 2004, 03:06 AM)
QUOTE(Garf @ Dec 18 2004, 05:47 PM)
SV7.1 is SV7 + PNS
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
I can't find any info regarding this. Is a command line switch required to use it, or does it "kick in" automatically at low bitrates? I so, how low? Plus, are there any updates required to foobar on the playback/decoding side of things, or will it play MPC+PNS files properly as is? Thanks all!
All not totally ancient decoders will play it.
Thanks for the info Garf. Is there any documentation that actually says what level PNS kicks in? Just curious if the above posts have been confirmed to be true or are just guesses. Thanks again!
QUOTE(Digisurfer @ Dec 23 2004, 07:00 PM)
Just curious if the above posts have been confirmed to be true or are just guesses.
You can use the --verbose switch to confirm by yourself.
This is the table of parameters for mppenc at various quality levels. As you can see, PNS does indeed kick in below --standard.
static const Profile_Setting_t Profiles [16] = {
{ 0 },
{ 0 },
{ 0 },
{ 0 },
{ 0 },
/* Short MinVal EarModel Ltq_ min Ltq_ Band- tmpMask CVD_ varLtq MS Comb NS_ Trans */
/* Thr Choice Flag offset TMN NMT SMR max Width _used used channel Penal used PNS Det */
{ 1.e9f, 1, 300, 30, 3.0, -1.0, 0, 106, 4820, 1, 1, 1., 3, 24, 6, 1.09f, 200 }, // 0: pre-Telephone
{ 1.e9f, 1, 300, 24, 6.0, 0.5, 0, 100, 7570, 1, 1, 1., 3, 20, 6, 0.77f, 180 }, // 1: pre-Telephone
{ 1.e9f, 1, 400, 18, 9.0, 2.0, 0, 94, 10300, 1, 1, 1., 4, 18, 6, 0.55f, 160 }, // 2: Telephone
{ 50.0f, 2, 430, 12, 12.0, 3.5, 0, 88, 13090, 1, 1, 1., 5, 15, 6, 0.39f, 140 }, // 3: Thumb
{ 15.0f, 2, 440, 6, 15.0, 5.0, 0, 82, 15800, 1, 1, 1., 6, 10, 6, 0.27f, 120 }, // 4: Radio
{ 5.0f, 2, 550, 0, 18.0, 6.5, 1, 76, 19980, 1, 2, 1., 11, 9, 6, 0.00f, 100 }, // 5: Standard
{ 4.0f, 2, 560, -6, 21.0, 8.0, 2, 70, 22000, 1, 2, 1., 12, 7, 6, 0.00f, 80 }, // 6: Xtreme
{ 3.0f, 2, 570, -12, 24.0, 9.5, 3, 64, 24000, 1, 2, 2., 13, 5, 6, 0.00f, 60 }, // 7: Insane
{ 2.8f, 2, 580, -18, 27.0, 11.0, 4, 58, 26000, 1, 2, 4., 13, 4, 6, 0.00f, 40 }, // 8: BrainDead
{ 2.6f, 2, 590, -24, 30.0, 12.5, 5, 52, 28000, 1, 2, 8., 13, 4, 6, 0.00f, 20 }, // 9: post-BrainDead
{ 2.4f, 2, 599, -30, 33.0, 14.0, 6, 46, 30000, 1, 2, 16., 15, 2, 6, 0.00f, 10 }, //10: post-BrainDead
}
CODE
static const Profile_Setting_t Profiles [16] = {
{ 0 },
{ 0 },
{ 0 },
{ 0 },
{ 0 },
/* Short MinVal EarModel Ltq_ min Ltq_ Band- tmpMask CVD_ varLtq MS Comb NS_ Trans */
/* Thr Choice Flag offset TMN NMT SMR max Width _used used channel Penal used PNS Det */
{ 1.e9f, 1, 300, 30, 3.0, -1.0, 0, 106, 4820, 1, 1, 1., 3, 24, 6, 1.09f, 200 }, // 0: pre-Telephone
{ 1.e9f, 1, 300, 24, 6.0, 0.5, 0, 100, 7570, 1, 1, 1., 3, 20, 6, 0.77f, 180 }, // 1: pre-Telephone
{ 1.e9f, 1, 400, 18, 9.0, 2.0, 0, 94, 10300, 1, 1, 1., 4, 18, 6, 0.55f, 160 }, // 2: Telephone
{ 50.0f, 2, 430, 12, 12.0, 3.5, 0, 88, 13090, 1, 1, 1., 5, 15, 6, 0.39f, 140 }, // 3: Thumb
{ 15.0f, 2, 440, 6, 15.0, 5.0, 0, 82, 15800, 1, 1, 1., 6, 10, 6, 0.27f, 120 }, // 4: Radio
{ 5.0f, 2, 550, 0, 18.0, 6.5, 1, 76, 19980, 1, 2, 1., 11, 9, 6, 0.00f, 100 }, // 5: Standard
{ 4.0f, 2, 560, -6, 21.0, 8.0, 2, 70, 22000, 1, 2, 1., 12, 7, 6, 0.00f, 80 }, // 6: Xtreme
{ 3.0f, 2, 570, -12, 24.0, 9.5, 3, 64, 24000, 1, 2, 2., 13, 5, 6, 0.00f, 60 }, // 7: Insane
{ 2.8f, 2, 580, -18, 27.0, 11.0, 4, 58, 26000, 1, 2, 4., 13, 4, 6, 0.00f, 40 }, // 8: BrainDead
{ 2.6f, 2, 590, -24, 30.0, 12.5, 5, 52, 28000, 1, 2, 8., 13, 4, 6, 0.00f, 20 }, // 9: post-BrainDead
{ 2.4f, 2, 599, -30, 33.0, 14.0, 6, 46, 30000, 1, 2, 16., 15, 2, 6, 0.00f, 10 }, //10: post-BrainDead
}
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.