Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: mppenc 1.16/libmpcdec 1.2.3 (Read 37075 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

mppenc 1.16/libmpcdec 1.2.3

Reply #25 –
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.
It's a 'Jump to Conclusions Mat'. You see, you have this mat, with different CONCLUSIONS written on it that you could JUMP TO.

mppenc 1.16/libmpcdec 1.2.3

Reply #26 –
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.
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.16/libmpcdec 1.2.3

Reply #27 –
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

mppenc 1.16/libmpcdec 1.2.3

Reply #28 –
Quote from: Seed on
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. 
In theory, there is no difference between theory and practice. In practice there is.

mppenc 1.16/libmpcdec 1.2.3

Reply #29 –
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.

mppenc 1.16/libmpcdec 1.2.3

Reply #30 –
Quote from: Alex B on
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.
It's a 'Jump to Conclusions Mat'. You see, you have this mat, with different CONCLUSIONS written on it that you could JUMP TO.
 

mppenc 1.16/libmpcdec 1.2.3

Reply #31 –
Quote from: Alex B on
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.
In theory, there is no difference between theory and practice. In practice there is.

mppenc 1.16/libmpcdec 1.2.3

Reply #32 –
Quote from: GeSomeone on
Quote from: Alex B on

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 from: Seed on
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. ...

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.

mppenc 1.16/libmpcdec 1.2.3

Reply #33 –
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.

mppenc 1.16/libmpcdec 1.2.3

Reply #34 –
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
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.16/libmpcdec 1.2.3

Reply #35 –
Thanks for the confirmation.

Quote from: Seed on
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.

mppenc 1.16/libmpcdec 1.2.3

Reply #36 –
This is like
                     
news.

Big fan of mpc

mppenc 1.16/libmpcdec 1.2.3

Reply #37 –
Quote from: Leto Atreides II on
Quote from: seanyseansean on


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?


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.

mppenc 1.16/libmpcdec 1.2.3

Reply #38 –
Nice to see it alive. Keep it up

mppenc 1.16/libmpcdec 1.2.3

Reply #39 –
This is indeed great & exciting news. An early Xmas present  Thanks.

mppenc 1.16/libmpcdec 1.2.3

Reply #40 –
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.

mppenc 1.16/libmpcdec 1.2.3

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

mppenc 1.16/libmpcdec 1.2.3

Reply #42 –
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