Musepack encoder 1.15s released Options

[Peter]

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

[music_man_mpc]

Finally!

[rjamorim]

Has Frank been involved in the development of this new version?

[Yaztromo]

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.

This post has been edited by Yaztromo: Nov 23 2004, 22:51

[Seed]

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.

[Zurman]

Is 1.15 the new officially recommanded version now?

[xmixahlx]

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

This post has been edited by xmixahlx: Nov 24 2004, 01:40

[music_man_mpc]

Oh well thats a little disappointing. I guess I rushed to conclusions when I saw the news. Oh well, at least its something.

[R.A.F.]

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.

This post has been edited by R.A.F.: Nov 24 2004, 06:47

[R.A.F.]

Is 1.15 the new officially recommended version now?

Sure not, because it´s still in alpha-status.

This post has been edited by R.A.F.: Nov 24 2004, 06:48

[Canar]

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.

[CiTay]

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.

[Canar]

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*

[ssamadhi97]

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

[Dologan]

I used to use 1.14 because I hated the alpha/experimental tag. No more. Thank you!

[NumLOCK]

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

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

On the UPX page 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.

[Lefungus]

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 

Random guess.
It may be due to the ESD dependency (Enlightened Sound Daemon, the old and deprecated gnome sound server).

[Seed]

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.

[NumLOCK]

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 

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

[xmixahlx]

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):

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

This post has been edited by xmixahlx: Nov 25 2004, 22:44

[ak]

Seems like profile bit is missed in sources?
It still shows 'Unstable/Experimental' (when built from source that is, binary works fine).

[xmixahlx]

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

This post has been edited by xmixahlx: Nov 25 2004, 22:49

[ak]

I'll try it, thanks.

[NumLOCK]

Just a note for those interested, a gentoo ebuild I updated for 1.15s can be found in bugs.gentoo.org