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: Do Musepack's inherently fast decoding speeds still mean anything? (Read 9669 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Do Musepack's inherently fast decoding speeds still mean anything?

SQ discussions apart, and as the title says, I wonder, at this day and age of major smart phone usage when it comes to portable listening (where obviously, music playback represents only a fraction of drained battery juices) whether Musepack's reportedly fast decoding speeds still hold a candle against other lossy CODECs in that department and, if that's still something worth taking into consideration.

Along with other opinions, I'd also like to hear those from people who, like me, still use it occasionally - not necessarily exclusively - when lossily enconding for, say, Android devices.
Listen to the music, not the media it's on.
União e reconstrução

Re: Do Musepack's inherent fast decoding speeds still mean anything?

Reply #1
I don't think it means anything now. Opus decoding is a lot cheaper on battery than virtually everything the phone has to do at the same time.
I used MPC for phone listening, then switched to Opus, and didn't notice any difference in terms of battery time.

Perhaps there could be some noticeable difference if I didn't have google apps on my phone and also always kept it in airplane mode, and didn't use any DSP effects in the player, and didn't touch it to see what's playing/to switch tracks/etc. But I never bothered to test a scenario which is not close to how I will use it in practice as this is practically pointless.
a fan of AutoEq + Meier Crossfeed

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #2
Yes, as I suspected, said low numbers are not something to toot one's own horn about anymore.

At least when it comes to the Foobar app's own decoding tests, I also concur with Opus being apparently, easy on power consumption.
Not to mention that, in terms of the ever-variable storage space in phones (say, when you shoot many videos) Opus's files' tiny footprint is a more-than-welcomed "feature".
Listen to the music, not the media it's on.
União e reconstrução

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #3
At least for me, things have undeniably changed along these last 10 or so years since the days of exclusive Rockbox-powered DAP usage... :o
Listen to the music, not the media it's on.
União e reconstrução

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #4
my guess with modern androids it means nothing. On my old retired samsung from 2011 , APE played up smooth until high mode. mp3 , ogg, musepack were developed on 90's pc hardware. On non pc cpu say 10-15 yrs back it may meant something and that also depended on platform optimisations. Take it forward to today cpus have nothing in common with 90's pc's. Moreover you can fit 100 albums lossless on a 32gb sdcard cost next to nothing .  I used mpc in the past on pc. I considered it from time to time .  Back in the day, you had the issue of compatibility and issue of disk space for lossless. Today space is usually not an issue for local storage. For low end sdcards / HW or streaming the space saving of lossy is still attractive - at least until we reach cheap 1TB + sdcards.. Creating multi lossy encodings today look a bit dumb (90's-00)  to me considering all this. I thought about about only lossless, instead settled for hybrid WV. On my PC playback is lossless , On my phone with 32gb sdcard I copy only the .wv. The lossy file is avg 273k with usually transparent result.

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #5
I'm surprised that folks are listing Opus as a rapid for decoding.  I suppose it makes a difference what you compare it to, but I wouldn't rate it highly for speed.  Maybe it makes a difference what sort of floating point hardware you've got?  My own experience is that Opus is slower than Vorbis (much slower than Musepack, not that I ever use it except for testing), but faster than HE-AAC.


Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #7
Quote
The lossy file is avg 273k with usually transparent result

Looks pretty bad in comparison to Opus which should be always transparent at half the bitrate.
a fan of AutoEq + Meier Crossfeed

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #8
On my old retired samsung from 2011 , APE played up smooth until high mode.
Meaning: that's where the CPU would drain battery as quickly as it possibly could.

Decoding speed <---> battery life, and that is still a potential concern. Not sure how much it matters in practice, but if saratoga's post referring to the 2010 results are representative, seems that one should use lossywav/lossyflac ... :-o

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #9
https://hydrogenaud.io/index.php/topic,82125.0.html

Musepack decoding speed is fast, but similar to codecs like vorbis or wma. I wouldn't say it's that different than anything else.
 

Decoding speed <---> battery life, and that is still a potential concern. Not sure how much it matters in practice, but if saratoga's post referring to the 2010 results are representative, seems that one should use lossywav/lossyflac ... :-o
 
But, as I innitially asked: do such speeds still matter now, 2018-19 (and henceforward), considering digital audio decoding makes up for just a small fraction of battery drainage?

Edit:
In short: should we still even bat and eyelid about such numbers?
Listen to the music, not the media it's on.
União e reconstrução

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #10
I thinks it's irrelevant now... modern smartphones have many small cores running background apps all day long, the added cycles needed to decode lossless formats at normal playback speed shouldn't be noticeable.
As saratoga said in that codec performance post: "Wavpack is probably fast enough that you wouldn't notice much difference in battery life verses flac.  Most devices can't lower the clock below 20MHz anyway."

How low do modern smartphones clock their processors today?

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #11
  Most devices can't lower the clock below 20MHz anyway."

How low do modern smartphones clock their processors today?
 
 

Hmm... that I didn't know!

Also, it automatically reminds me of the old 386SX PC of yore in all its 25MHz glory (I did encoded "Lame --r3mix" MP3s in one of those, if memory serves me well, back in '98!!) and how we had to use clock reductors to bring such "amazing" speed down to the XT PC's 4.7MHz(?) in order to run some old games on interpreted BASIC! :P

Boy, time most definitely flies! :))
Listen to the music, not the media it's on.
União e reconstrução

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #12
On my old retired samsung from 2011 , APE played up smooth until high mode.
Meaning: that's where the CPU would drain battery as quickly as it possibly could.

Decoding speed <---> battery life, and that is still a potential concern. Not sure how much it matters in practice, but if saratoga's post referring to the 2010 results are representative, seems that one should use lossywav/lossyflac ... :-o

One thing I can say for sure since i listen to a lot of online radio, HE-AAC on the old phone drained battery and made it warm -- this was one of the best stress test cases though playback was fine. WV played all modes smooth and cool inc -hh lossy which is slowest.  APE fast -c1000 mode took similar cpu as wv -hh lossy. Now I have a J2 PRO samsung it doesn't even sweat it on HE-AAC streams.  In comparison battery lasts much longer no matter what i do on it.

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #13
Claims about Decoding speed (unrelated to musepack) have quite often struck me as odd. I have many times considered making a threat about it, but wasn't sure how to phrase it. For example on this website we find the claim that Opus is supposed to be about as fast as AAC and musepack is supposed to be about as fast as Mp3, both being faster (almost 3 times) than Opus and AAC.

I absolutely can not reproduce this behaviour. A quick test on my random laptop using the decoding speed test plugin in foobar2000 (single threaded) gives me about 252x realtime speed for Opus, 587x realtime speed for Musepack, ~715 realtime speed for Mp3 and a whopping ~1600x realtime speed for AAC. Maybe this has something to do with hardware decoding support? Or the AAC decoder in ffmpeg has recently been improved? I guess it would also depend on architecture... x86 vs AMD64 vs ARM.

I just can almost never correlate benchmark results I've seen online with what I experience in the real world. Do you know more about this @saratoga ? I think you have some know-how on decoder ... things?

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #14
AAC in particular has a lot of entirely unrelated decoding software and is itself effectively at least two different codecs, one of which is much slower to decode.  I think the Apple decoder is fast, but which hardware should you do the comparison on?  Linux has all sorts of AAC decoders available, with speed and quality all over the place.  It is still surprising to see AAC of any kind decoding dramatically faster than MP3 of any kind, you should probably look for the reasons why and that would tell you a lot.

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #15
I think the Apple decoder is fast, but which hardware should you do the comparison on?  Linux has all sorts of AAC decoders available, with speed and quality all over the place.  It is still surprising to see AAC of any kind decoding dramatically faster than MP3 of any kind, you should probably look for the reasons why and that would tell you a lot.

Yeah but that's kinda my point about 'real world tests'. Shouldn't you compare the fastest possible implementations of the decoders? I don't think comparing the decoding speed of the reference implementations of the decoders makes any sense at all (opusdec.exe vs apple_aac_lc_dec.exe or whatever it is called). I imagine they are often not optimized for speed at all. Just comparing the ffmpeg decoding speed might be okay, since it and its decoders are so widely used.

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #16
Claims about Decoding speed (unrelated to musepack) have quite often struck me as odd. I have many times considered making a threat about it, but wasn't sure how to phrase it. For example on this website we find the claim that Opus is supposed to be about as fast as AAC and musepack is supposed to be about as fast as Mp3, both being faster (almost 3 times) than Opus and AAC.

I absolutely can not reproduce this behaviour. A quick test on my random laptop using the decoding speed test plugin in foobar2000 (single threaded) gives me about 252x realtime speed for Opus, 587x realtime speed for Musepack, ~715 realtime speed for Mp3 and a whopping ~1600x realtime speed for AAC. Maybe this has something to do with hardware decoding support? Or the AAC decoder in ffmpeg has recently been improved? I guess it would also depend on architecture... x86 vs AMD64 vs ARM.

I just can almost never correlate benchmark results I've seen online with what I experience in the real world. Do you know more about this @saratoga ? I think you have some know-how on decoder ... things?

Unless you spent 5 years optimizing each of the codecs in assembly like I (and others) did for that comparison I linked, you can't really do that. You don't know how fast an optimized decoder would be on a given device, only how fast some specific windows application is, and that will probably be uncorrelated with mobile device power consumption.

In reality, mp3 is pretty slow, most things are faster at a similar level of optimization due to the hybrid filterbank. Opus is probably a bit slower or maybe the same as mp3. WMA is probably the fastest modern codec, followed closely by MPC and then Vorbis and AAC.

This probably doesn't matter on an Android device. These are all using low power dsp chips for decode such that decoder time is negligible compared to other things. In rockbox it matters a lot more since there is nothing but decode consuming power.

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #17
Musepack can still be a good choice IMO for several reasons:

- open source, single implementation, well maintained
- fast decoding / encoding with reference encoder.
- gapless design vs mp3 / aac
- Subband codec, less or no pre echo.
- Set it and forget it by design; HQ pure VBR encodings and optimised at default parameters
- Resonably compact filesize at default and --extreme settings ; smaller than typical 256..320 aac/mp3/ogg
- Mature, tested code even though no longer evolving. That could also be a plus for stability.
- Still competitive for mid bitrates 128k or higher
- Reasonable playback options on android and some on IOS. Reported to work well on rockbox.


Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #18
Musepack can still be a good choice IMO for several reasons:

Potentially one more: If I ever find a musepack file, I don't need to ask myself if it is what I acquired or not - I will know that I have transcoded it myself.

 

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #19
Musepack can still be a good choice IMO for several reasons:

Potentially one more: If I ever find a musepack file, I don't need to ask myself if it is what I acquired or not - I will know that I have transcoded it myself.


Can be achieved more consistently by signing files with your private key. And it will work for any type of files.
a fan of AutoEq + Meier Crossfeed

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #20
Can be achieved more consistently by signing files with your private key. And it will work for any type of files.
Broken at every tag update, and is not "human-readable" ... but sure, if I were a computer.

Re: Do Musepack's inherently fast decoding speeds still mean anything?

Reply #21
Of course you will need to sign files again if they are changed.
There's also an option to just put your own files into a different folder which never contains "third party" files. Unless someone breaks into your stuff, these "wrong" files won't just appear out of nowhere.
a fan of AutoEq + Meier Crossfeed