Musepack.net forum thread (http://www.musepack.net/forum/viewtopic.php?t=97)
A new mppenc version is out. It includes some small fixes and changes.
mppenc 1.15s (Windows) (http://www.musepack.net/index.php?pg=win)
mppenc 1.15s (Linux) (http://www.musepack.net/index.php?pg=lin)
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 (http://www.musepack.net/index.php?pg=src)
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.
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
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.
Is 1.15 the new officially recommended version now?
[a href="index.php?act=findpost&pid=255801"][{POST_SNAPBACK}][/a]
Sure not, because it´s still in alpha-status.
Sure not, because it´s still in alpha-status.
[a href="index.php?act=findpost&pid=255856"][{POST_SNAPBACK}][/a]
mppenc 1.15
r 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.
1.15s output is identical to 1.15r (do an inverse mix-paste)[a href="index.php?act=findpost&pid=256029"][{POST_SNAPBACK}][/a]
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*
Is 1.15 the new officially recommended version now?
[a href="index.php?act=findpost&pid=255801"][{POST_SNAPBACK}][/a]
Sure not, because it´s still in alpha-status.
[a href="index.php?act=findpost&pid=255856"][{POST_SNAPBACK}][/a]
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.
[span style='font-size:8pt;line-height:100%']*: 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[/span]
I used to use 1.14 because I hated the alpha/experimental tag. No more. 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
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 (http://upx.sourceforge.net/#unstable) what is quoted below is a direct 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.
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
[a href="index.php?act=findpost&pid=256103"][{POST_SNAPBACK}][/a]
Random guess.
It may be due to the ESD dependency (Enlightened Sound Daemon, the old and deprecated gnome sound server).
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.
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
[a href="index.php?act=findpost&pid=256103"][{POST_SNAPBACK}][/a]
Random guess.
It may be due to the ESD dependency (Enlightened Sound Daemon, the old and deprecated gnome sound server).
[a href="index.php?act=findpost&pid=256119"][{POST_SNAPBACK}][/a]
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 (http://xmixahlx.dyndns.org/audio/files/linux/musepack/dev/1.15s-linux_xmixahlx4.tar.bz2) or browse (http://xmixahlx.dyndns.org/audio/files/linux/musepack/dev/1.15s-development/)
later
Seems like profile bit is missed in sources?
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
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?
hmm... where's the binary?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=256447")
In a hidden box behind your toolshed.
A new mppenc version is out. It includes some small fixes and changes.
[a href="http://www.saunalahti.fi/grimmel/mpc/windows/encoder/mppenc-windows-1.15s.zip]mppenc 1.15s (Windows)[/url]
mppenc 1.15s (Linux, static) (http://www.saunalahti.fi/grimmel/mpc/linux/encoder/mppenc-linux-libc6-static-1.15s.zip)
mppenc 1.15s (Linux, dynamic) (http://www.saunalahti.fi/grimmel/mpc/linux/encoder/mppenc-linux-libc6-1.15s.zip)[a href="index.php?act=findpost&pid=255765"][{POST_SNAPBACK}][/a]
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?
[a href="index.php?act=findpost&pid=256454"][{POST_SNAPBACK}][/a]
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.
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
MPC Encoder 1.15s --Alpha-- © 1992-2002 Buschmann/Klemm/Piecha
then be changed into
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.
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
MPC Encoder 1.15s --Alpha-- © 1992-2002 Buschmann/Klemm/Piecha
then be changed into
MPC Encoder 1.15s Beta © 1992-2002 Buschmann/Klemm/Piecha
?
[a href="index.php?act=findpost&pid=256471"][{POST_SNAPBACK}][/a]
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...
http://www.rarewares.org/files/mpc/mpp-1.15r-MacOSX.tar.bz2 (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
http://www.rarewares.org/files/mpc/mpp-1.15r-MacOSX.tar.bz2 (http://www.rarewares.org/files/mpc/mpp-1.15r-MacOSX.tar.bz2) [a href="index.php?act=findpost&pid=257793"][{POST_SNAPBACK}][/a]
Thanks, but I was looking for the latest version.
Version 1.15
s, not an old version dated 19.05.2004.
Thanks, but I was looking for the latest version.
Version 1.15s, not an old version dated 19.05.2004.
[a href="index.php?act=findpost&pid=257797"][{POST_SNAPBACK}][/a]
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?
SV7.1 is SV7 + PNS
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
Thanks, but I was looking for the latest version.
Version 1.15s, not an old version dated 19.05.2004.
[a href="index.php?act=findpost&pid=257797"][{POST_SNAPBACK}][/a]
The latest "offical" (www.musepack.net) compile for Mac OS X is still at version 1.15r.
[a href="index.php?act=findpost&pid=258176"][{POST_SNAPBACK}][/a]
We should have 1.15s builds for the mac up shortly.
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.
[a href="index.php?act=findpost&pid=261157"][{POST_SNAPBACK}][/a]
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.
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,
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=261157")
Seek time on Playback is mainly a decoder issue, see also [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=27343]this foobar topic[/url]. This encoder version will not make a difference in that respect.
SV7.1 is SV7 + PNS
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
[a href="index.php?act=findpost&pid=260596"][{POST_SNAPBACK}][/a]
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!
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!
[a href="index.php?act=findpost&pid=261301"][{POST_SNAPBACK}][/a]
Ummm...
Thanks Garf, it seems to kick in from below "Standard"
SV7.1 is SV7 + PNS
The new encoder should produce this when you use low bitrates, it's not used for higher ones.
[a href="index.php?act=findpost&pid=260596"][{POST_SNAPBACK}][/a]
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!
[a href="index.php?act=findpost&pid=261301"][{POST_SNAPBACK}][/a]
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!
Just curious if the above posts have been confirmed to be true or are just guesses.
[a href="index.php?act=findpost&pid=261406"][{POST_SNAPBACK}][/a]
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
}
Since 28th of January a new version of the MPC-encoder-engine is available:
mppenc 1.15
t. For download just click
HERE (http://files.musepack.net/windows/encoder/mppenc-windows-1.15t.zip) (Windows-version) or
HERE (http://files.musepack.net/linux/encoder/mppenc-linux-libc6-1.15t.bz2) (Linux dynamic-linked version).
mppenc 1.15t is out. It handles teh_sample properly now. The problem was a result
of aggressive compiler settings in previous versions.
The new versions for both Windows and Linux are now compiled by ak using GCC. It
allows for easier maintenance and ensures that we release compatible binaries
that produce the exact same encoded files.
The new encoder should produce files with a bitrate similar to 1.15s, but in many
cases slightly lower or higher (1-2 kbps at --standard). We've thoroughly tested it
on a Pentium 3, Pentium 4, Athlon, Athlon XP, Athlon 64, G5 (Mac). Speed is mostly
the same as before but on some computers it is slightly lower. Frank Klemm
advises to be very careful when compiling with certain flags and we've
followed this advice.
http://www.hydrogenaudio.org/forums/index....topic=31055&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=31055&hl=)
http://www.hydrogenaudio.org/forums/index....topic=31055&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=31055&hl=)
[a href="index.php?act=findpost&pid=270334"][{POST_SNAPBACK}][/a]
Sorry, "blinded by science".