Hydrogenaudio Forums > mppenc 1.16/libmpcdec 1.2.3

Full Version: mppenc 1.16/libmpcdec 1.2.3

Hydrogenaudio Forums > Hydrogenaudio Forum > Validated News

Seed

Nov 12 2006, 14:01

Musepack encoder version 1.16 and libmpcdec 1.2.3 are released.

libmpcdec 1.2.3 enables a new, fast method for seeking, and additionally, a seek table, the result of which is generally instant seeking. On very long tracks you will sometimes notice a delay when seeking from beginning to the end of the track. However, on consecutive seeks playback resumes instantly.

On files that were encoded with an encoder older than 1.16 fast seeking is not bit-perfect. The reason is that sometimes, due to the way older encoders inject scale factors to the stream, the new seeking method may replace a very high frequency band with silence for a period of a few milliseconds and in rare cases up to a second or so.

In our testing we haven't found any case where that is actually audible. Other than a theoretical very slightly different sounding output for a very short time period after seeking, there is no other artifact that can be caused by the fast seeking, so for all practical purposes it is perfectly fine on older as well as newer files.

The new encoder version differs mainly in the way it injects scale factors to the stream. This enables bit perfect seeking at all times with the new decoding library.

Special thanks goes to snowgoon for the initial seeking patches, R2D, for developing it further and adding features, Lefungus, for doing lots of library work, encoder patching and advising, and xmixahlx for his loads of testing, compiling, patching and support.

1.16 is probably the last SV7 encoder. All efforts are now directed at building SV8. Development can be followed on our Trac and SVN repositories.

Decoder library changelog:

QUOTE

1.2.3
* Added fast-seeking (bit-perfect only with mppenc 1.16 files and later, optional but safe on pre-mppenc 1.16 files). Patch by Nicolas Botti
* Reduced memory usage and code size. Patch by Peter Pawlowski

Encoder changelog:

QUOTE

1.16:
* Add fast seeking flag in reserved header data. Enable bit-perfect fast seeking. Patch by Andrew Cupper & Nicolas Botti
* Add optional beeping at the end of encoding (--beep)
* Remove tag guessing from filename on UNIX
* Add Unicode input support for tags (--unicode) (UNIX only). Patch by Valery Bruniaux
* Frontend patches from xmixahlx & Shy
* Code clean-up
* Port build system to cmake for UNIX & msvc2005 for win32

1.15v
* Workaround for denormal number issues. Synthetic samples with passages of digital silence are handled correctly regardless of the compiler used
* Translation of German source code comments to English. Patch by CiTay & Seed

1.15u
* Changes in the way the encoded signal is padded to MPC frame boundaries. Beginning and end of track encoding is handled differently, resulting in significantly improved gapless coding. Thanks to Xiph's Monty for the initial advice

1.15t
* Aggressive compiler settings could cause a glitch in rare synthetic samples

1.15s
* In some rare cases, the output file would have an incorrect duration (4 missing samples) when encoding some very long tracks
* There was a glitch at the end of the track when encoding from a 24-bit source through pipe
* --xlevel is used by default. Use --noxlevel to override
* Removed "Unstable/Experimental" flag writing

mppenc 1.16 for Windows
mppenc 1.16 for Linux / mppenc 1.16 source code
libmpcdec 1.2.3

discussion on the Musepack forum

xmixahlx

Nov 12 2006, 14:29

in addition, xmms-musepack has been updated to utilize fast-seeking with the 1.2.1 release.

the feature is a toggle in the decoder plugin options (enable/disable fast seeking).

webpage: http://www.musepack.net/index.php?pg=lin
tarball: http://files.musepack.net/linux/plugins/xm...k-1.2.1.tar.bz2

also, rarewares/debian is updated with: libmpcdec, mppenc (musepack-encoder), and xmms-musepack

later

TrNSZ

Nov 12 2006, 15:29

Also worth mentioning that foobar2000 0.9.4.2b and higher supports MusePack fast seeking.

ilikedirtthe2nd

Nov 12 2006, 15:46

QUOTE(TrNSZ @ Nov 12 2006, 22:29)

Also worth mentioning that foobar2000 0.9.4.2b and higher supports MusePack fast seeking.

Only for files created by the new encoder.

Any news on a tool to losslessly convert older mpc files to SV 7.2? (was mentioned in the musepack.net forums)

Canar

Nov 12 2006, 16:02

Musepack forever!

Thanks for your work guys. Good luck on getting past SV7. I eagerly await your results.

Seed

Nov 12 2006, 16:04

The task of writing such a tool was not assigned to any developer. If there's demand for one it'll eventually be created. Any player can enable fast seeking on older files but because of caution and lack of massive testing by enough users this option is still disabled.

ilikedirtthe2nd

Nov 12 2006, 16:10

QUOTE(Seed @ Nov 12 2006, 23:04)

Okay, thank you!

CiTay

Nov 12 2006, 16:36

Great work, guys. I just encoded a long single-file album with it, and seeking has no delay whatsoever with the new foobar2000 beta. Pretty nice.

MyMaster

Nov 12 2006, 16:41

is the radio preset broken? everytime i try to use it the encoder crashes / EAC / CDEX / FOOBAR all the same.

thank you

Tim Mervielde

Nov 12 2006, 17:06

I think there is a mistake in mppenc.c in the ms channel mode column: --ms used to be 10 for the -radio preset, --ms 6 is undefined in psy.c

CODE

/*    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

seanyseansean

Nov 12 2006, 17:15

Wow, unexpected but fantastic news. Thanks to the devs.

That said, i've just reencoded 200gb of flac files to 1.15 standard profile and this appears

Tim Mervielde

Nov 12 2006, 17:15

Sorry, I was wrong, it was always 6 in the code, but on the command line it was --ms 10

CiTay

Nov 12 2006, 17:22

QUOTE(seanyseansean @ Nov 13 2006, 00:15)

That said, i've just reencoded 200gb of flac files to 1.15 standard profile and this appears

No sweat. Audio quality hasn't changed, and in a future version of foobar2000, fast seeking can/will be enabled for all MPC files. As Seed said in the first post, it won't be bit-perfect (will be for 1.16 encodes), but you won't hear any glitches either, so all is good.

QUOTE

is the radio preset broken?

They're already working on it. Expect updated files soon.

edit: New foobar2000 released, fast seeking works for all files now!

seanyseansean

Nov 12 2006, 17:29

QUOTE(CiTay @ Nov 12 2006, 23:22)

QUOTE(seanyseansean @ Nov 13 2006, 00:15)

That said, i've just reencoded 200gb of flac files to 1.15 standard profile and this appears

Thank you.

Although it seems yesterdays codec to a lot of people, I did look at other alternatives before my big reencode and this is what I surmised:

1. I didn't want to use mp3 because the flaws inherent in that format were easily audible at any bitrate to *my* ears. I can see which pub jukeboxes use mp3 just from this.

2. Last time I checked ogg it wasn't competitive with MPC. I hear good things about aotuv builds, but I had problems with battery suckage on rockbox.

3. AAC seems too fragmented for my poor tiny mind. Plenty of different encoders/decoders, different profile sets, blah. Also the same battery suckage as rockbox

It'd be nice to see MPC do well again. A nice single encoder, excellent quality at 170~kbps, and fast decode.

If i'm wrong on any of these points, feel free to point it out people.

xmixahlx

Nov 12 2006, 18:11

a bug that was borking mppenc with low qualities (<standard) has been fixed - it is now ready for mass consumption.

apologies for the false start

please redownload the binaries if you downloaded the files before 1600 PST today. they are available at the same URLs as in the first post.

rarewares/debian is updated as well

later

TrNSZ

Nov 12 2006, 18:13

Thanks for the fix - I was just about to come here and report it. Great work.

Lefungus

Nov 12 2006, 18:15

Sorry about the bug, it was a dumb mistake from me. Rejoice, it's corrected already. And I'll go to sleep before anyone else find another one

skelly831

Nov 12 2006, 20:52

Holy codec resurrection batman!

This is certainly interesting news, thanks to the devs and everyone involved

shadowking

Nov 13 2006, 00:53

I've tested a few tracks with foobar 09.4.2 and seeking appears to work without a hitch. Nice work !

Leto Atreides II

Nov 13 2006, 01:01

QUOTE(seanyseansean @ Nov 12 2006, 15:29)

2. Last time I checked ogg it wasn't competitive with MPC. I hear good things about aotuv builds, but I had problems with battery suckage on rockbox.

3. AAC seems too fragmented for my poor tiny mind. Plenty of different encoders/decoders, different profile sets, blah. Also the same battery suckage as rockbox

I'm a die-hard MPC fan myself, but I'm just curious that you raised these points... Did you not see battery suckage with MPC?

Firon

Nov 13 2006, 01:09

Vorbis IS competitive with MPC (the aoTuV builds anyway). And last I recall, guruboolez' last listening test with MPC and Vorbis (aoTuV b4) showed that Vorbis was statistically better at 170-180kbps, nevermind lower bitrates.
http://www.hydrogenaudio.org/forums/index....howtopic=36465#
And this was only with aoTuV b4. Improvements have been made since then (for AAC too, but AAC encoders confuse me

), so the gap might very well be larger now.

As for battery suckage, that's probably just because Rockbox is not very optimized (though Vorbis IS a bit of a CPU whore)

vinnie97

Nov 13 2006, 01:13

QUOTE(seanyseansean @ Nov 12 2006, 15:29)

2. Last time I checked ogg it wasn't competitive with MPC. I hear good things about aotuv builds, but I had problems with battery suckage on rockbox.

This point being raised is also suspect. When was the last time you checked? I'd say they are neck and neck at this point (Vorbis excelling at lower bitrates) and no recent listening tests have suggested otherwise. I second the point about Rockbox. The implementation of Rockbox itself regardless of the format causes "battery suckage."

Alex B

Nov 13 2006, 01:56

QUOTE(ilikedirtthe2nd @ Nov 12 2006, 23:46)

QUOTE(TrNSZ @ Nov 12 2006, 22:29)

Also worth mentioning that foobar2000 0.9.4.2b and higher supports MusePack fast seeking.

Only for files created by the new encoder. ...

QUOTE(Seed @ Nov 13 2006, 00:04)

... Any player can enable fast seeking on older files but because of caution and lack of massive testing by enough users this option is still disabled.

I don't think this option is disabled in foobar2000 v. 0.9.4.2 beta. I just tried seeking some old 80-minute Musepack v. 1.14 files. It was clearly a lot faster than before.

seanyseansean

Nov 13 2006, 02:01

QUOTE(vinnie97 @ Nov 13 2006, 07:13)

QUOTE(seanyseansean @ Nov 12 2006, 15:29)

2. Last time I checked ogg it wasn't competitive with MPC. I hear good things about aotuv builds, but I had problems with battery suckage on rockbox.

As I said it was a while ago. The other formats however definitely suck more battery on my ipod/rockbox than MPC, and the same is true on tcpmp/smartphone.

Bear in mind I wasn't likely to change codec for my 200gb reencode unless there was a substantial gain over MPC.

George_007

Nov 13 2006, 02:56

The link for the encoder binary for linux on http://www.musepack.net seems to point to the source.

Lefungus

Nov 13 2006, 03:20

Binary compatibility for all linux distributions is still a wild dream so only source is given with linux package.
It should be easy to build your own version, read INSTALL file. if you're on debian, xmixahlx have precompiled packages for you. If you're not on debian, you can ask your distro maintainers to update their packages.

Seed

Nov 13 2006, 03:40

Alex B: older files seek faster because of the way the new lib handles them. The foobar beta still does not allow 1.16-quick seeking on old files but you are right that it's faster than in previous versions.

As for RockBox support, their devs say the Musepack codec boosts less than most other lossy codecs. That means it uses less CPU time. I did not hear of worse battery time claims. On the iRiver (ARM) there is no boost (CPU is throttled normally and boost means it jumps to full speed) for MP3 and MPC (not even with --quality 10). If I find time I'll borrow a G3 iPod and flash it with RockBox. I'll load it with Vorbis/MP3/MPC files to test battery time myself.

xmixahlx

Nov 13 2006, 03:57

the closest you'll find to codec benchmark tests for rockbox are here:
http://www.rockbox.org/twiki/bin/view/Main...manceComparison

of the formats tested - musepack, mp3 and flac are the most efficient (no cpu boost) while vorbis and aac/mp4 are the least efficient (some to high boost). you may have guessed that with cpu boost comes less battery life.

i've been very happy with my iriver h320, and - luckily for my huge musepack archive - musepack is a very good choice for rockbox.

a forum thread on rockbox.org is also a good place for codec comparisons, here:
http://forums.rockbox.org/index.php?topic=6786.0

later

GeSomeone

Nov 13 2006, 05:34

QUOTE(Seed @ Nov 13 2006, 11:40)

Any player can enable fast seeking on older files but because of caution and lack of massive testing by enough users this option is still disabled. [...] The foobar beta still does not allow 1.16-quick seeking on old files ...

If the foobar2000 devs need an extra beta-tester for this ... Just let me know.

Alex B

Nov 13 2006, 06:06

Seed,

Would building a new decoder plugin for a player program be exactly similar process as before? I mean, could a developer just take the new library and repeat the same steps he/she did with the previous decoding library?

I am asking this because J. River made a new Musepack decoder plugin for their Media Center program less than a year ago. This happened after the update was requested in their user forum a few times. Obviously it was not a very simple task. After considerable amount of bug hunting they got it right. (In which I assisted a bit during this Media Center forum thread: http://yabb.jriver.com/interact/index.php?topic=30834.0

)

I could inform that a new decoding library is available and ask them to update the plugin again.

Lefungus

Nov 13 2006, 07:04

QUOTE(Alex B @ Nov 13 2006, 13:06)

Would building a new decoder plugin for a player program be exactly similar process as before? I mean, could a developer just take the new library and repeat the same steps he/she did with the previous decoding library?

They seem to use libmpcdec-1.2.2.
Libmpcdec-1.2.3 is backwards compatible with all 1.2 versions, so unless they modified libmpcdec sources, updating their plugin should just be a new compile with fresh sources. No code-source modifications needed.

GeSomeone

Nov 13 2006, 07:06

QUOTE(Alex B @ Nov 13 2006, 14:06)

I am asking this because J. River made a new Musepack decoder plugin [..]
I could inform that a new decoding library is available and ask them to update the plugin again.

Consider if there is a seeking problem on J.River's else it would not be worth doing so.

Alex B

Nov 13 2006, 08:37

QUOTE(GeSomeone @ Nov 13 2006, 15:06)

QUOTE(Alex B @ Nov 13 2006, 14:06)

I am asking this because J. River made a new Musepack decoder plugin [..]
I could inform that a new decoding library is available and ask them to update the plugin again.

Consider if there is a seeking problem on J.River's else it would not be worth doing so.

It does not have a problem, but if I have understood this correctly, seeking would be faster with old files and especially with newly encoded v. 1.16 files.

QUOTE(Seed @ Nov 13 2006, 11:40)

Let me get this right. Are the following assumptions correct?

- The files that are encoded with the new encoder version and decoded using the new decoding library can be sought bit perfectly. A decoder that is based on the new library uses the new quick seeking feature automatically with v. 1.16 files.

- This new quick seeking feature is not enabled for older Musepack files, but it could be. With old files (pre 1.16) the audio output immediately after seeking would not be exactly bit perfect when compared with "unsought" output of the same file. This difference would probably not be audible because it exists only in the highest frequencies and after a very short while the output would be correct again.

- Other improvements in the new decoding library make seeking of old Musepack files faster even this new quick seeking feature is disabled for old files.

sld

Nov 13 2006, 11:00

There is still a perceptible delay with seeking pre-1.16 encoded mpcs on songs over 7 minutes, on my setup (Core Duo 1.83 GHz, 5400rpm HDD)). There is a significant improvement though. By comparing seeking between mp3s (instantaneous on re-seeking back and forth) and mpcs (constant perceptible delay) of similar length, I am quite convinced that fast seeking is most likely disabled in the Foobar beta.

Seed

Nov 13 2006, 11:25

QUOTE

- The files that are encoded with the new encoder version and decoded using the new decoding library can be sought bit perfectly. A decoder that is based on the new library uses the new quick seeking feature automatically with v. 1.16 files.

- This new quick seeking feature is not enabled for older Musepack files, but it could be. With old files (pre 1.16) the audio output immediately after seeking would not be exactly bit perfect when compared with "unsought" output of the same file. This difference would probably not be audible because it exists only in the highest frequencies and after a very short while the output would be correct again.

- Other improvements in the new decoding library make seeking of old Musepack files faster even this new quick seeking feature is disabled for old files.

This is all correct

Alex B

Nov 13 2006, 12:42

Thanks for the confirmation.

QUOTE(Seed @ Nov 13 2006, 00:04)

Any player can enable fast seeking on older files but because of caution and lack of massive testing by enough users this option is still disabled.

This sounds a bit like the chicken and the egg dilemma.

Any chance of getting a test version of foobar for testing this?

I guess that during standard playback a small and possibly inaudible quality change after seeking would always be less irritating than a longer seek time.

The only potential problem I can think of would be with track file conversions from mpc disc image file & cue sheet sources if the cue playback system uses the same seeking mechanism.

budbrain

Nov 14 2006, 15:18

This is like

news.

Big fan of mpc

Mike Giacomelli

Nov 14 2006, 21:26

QUOTE(Leto Atreides II @ Nov 13 2006, 00:01)

QUOTE(seanyseansean @ Nov 12 2006, 15:29)

I'm a die-hard MPC fan myself, but I'm just curious that you raised these points... Did you not see battery suckage with MPC?

I believe MPC is actually the fastest lossy format in Rockbox, at least on the Ipod, so it should use much less power then MP3, Ogg or AAC. I suspect battery life will still not be great though since Rockbox on the Ipod isn't very far along. On the Iriver or Iaudio players though, battery life should be ridiculous since the Rockbox ports are so efficient and MPC itself is so fast.

rutra80

Nov 15 2006, 14:12

Nice to see it alive. Keep it up

rectangle

Nov 16 2006, 02:46

This is indeed great & exciting news. An early Xmas present

Thanks.

CiTay

Nov 20 2006, 13:58

foobar2000 v0.9.4.2 beta 2 is out:

http://www.foobar2000.org/beta/index.html

Now fast seeking is used for all MPC files.

user

Dec 7 2006, 10:37

really nice progress, already encoding new albums with mpc 1.16 (and Case's flac 1.1.3)

xmixahlx

Dec 10 2006, 21:08

a bug-fix of libmpcdec 1.2.3 prompts the release of...

libmpcdec 1.2.4 (surprise!)

the musepack.net frontpage is updated &
packages at rarewares/debian are updated, also.

later

chrisbowd

Jan 4 2007, 22:42

As one of those "old" 2000 - 2002 users who most said should have moved on (but didn't) this is wonderful news.

Is there a way for people to support this development? It seems to me there are a lot of people out there happy to bitch and whine about nobody developing their free software but few prepared to actively do anything about it.

Thanks to the developers involved for putting their time into this!

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.