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: Compressing Lossless to Lossy - Codec Recommendations ? (Read 27243 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Compressing Lossless to Lossy - Codec Recommendations ?

I need to compress some lossless files to lossy for storage/use on my mobile phone. I am thinking to use musepack (mpc) as it's supposed to sound quite good at higher bitrates, my phone has no problem playing mpc.
Before I start the task though, I thought I might come here and ask opinions as to whether mpc is a good choice, and why/why not. Also any recommendations/thoughts are quite welcome.
Thank You  :P

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #1
Considering high bitrates you are about to use, it really doesn't matter which MODERN lossy codec you are about to use - so, why not using something that can be decoded by hardware, like aac? To conserve batteries.
IIRC, mpc is almost always decoded by software on mobile phones.
Error 404; signature server not available.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #2
Considering high bitrates you are about to use, it really doesn't matter which MODERN lossy codec you are about to use - so, why not using something that can be decoded by hardware, like aac? To conserve batteries.
IIRC, mpc is almost always decoded by software on mobile phones.
You make a good point if it's true (I don't know that much about it)
Android has hardware decoding ability for aac and this would conserve battery?
This is the sort of input I was looking for, thank you

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #3
MPC --standard or --extreme (180~210k) may be good choice. Its very fast and could be better quality than AAC /MP3 256~320k.  Mp3 has some technical limitations and AAC /OGG / opus have not had extensive testing or tuning at high bitrates.

At 200+ k mp3 can be a good choice and potentially more stable than the others except mpc which was designed for mid-high bitrate. You can also try the lame3995o mp3 variant @ Q1 setting.


Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #5
Considering high bitrates you are about to use, it really doesn't matter which MODERN lossy codec you are about to use - so, why not using something that can be decoded by hardware, like aac? To conserve batteries.
IIRC, mpc is almost always decoded by software on mobile phones.

Are there actually any hardware decoders? Don't they net out to be software embedded in firmware running on more-or-less DSP-like or other computer hardware?  These lines seem to be pretty blurred to me. Can you give some factual examples to shed some light?

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #6
True ASIC decoders aren't used anymore. On smartphones there is a highly power efficient DSP core  running a software decoder. This is what people mean by hardware.

On Android devices using Qualcomm hardware the decoder is a hexagon DSP. I'm not sure what Samsung uses in their exynos cores.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #7
True ASIC decoders aren't used anymore. On smartphones there is a highly power efficient DSP core  running a software decoder. This is what people mean by hardware.

On Android devices using Qualcomm hardware the decoder is a hexagon DSP. I'm not sure what Samsung uses in their exynos cores.

When I bought a Galaxy S3, I was looking for Exynos DSP details but only bothered to go as far as digging up an ancient PDF for the 4412 Quad.  I don't remember it being too revealing.

OP: I recently ran my own little battery consumption test on a dusty, old Samsung i9305.  The Rockbox site already has oodles of data on decoding speeds of compression formats but I just wanted an idea of how different they could be on that old Exynos chipset.  I installed LineageOS and a solitary app (VLC) on the phone.  I charged to 100%, cleared all recent apps, turned off the radios.  Finally I pulled the cord out and played a single album.  I noted down Android's self-reported battery stats before recharging to 100%, clearing, etc. and running the test again.  Unfortunately, I didn't use MPC but I've attached the results to this post (LibreOffice ODS file).

Suffice to say, the differences are negligible and I suspect unnoticeable on a phone running many other processes so I wonder whether you concern yourself too much with battery consumption in your choice.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #8
All audio formats use negligible CPU power on a modern phone.  The reason a DSP is used is not to save CPU cycles, but rather to avoid having the CPU awake at all.  Turning it on and then having it sit there 99% idle wastes considerable power.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #9
Indeedy.  Qualcomm annually sing the praises of the latest Hexagon offering on-board their Snapdragon but you rarely hear anything from your Samsungs, Mediateks or other ARM licensees.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #10
So... aac, then? :)
Error 404; signature server not available.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #11
chrome_waves,
Good start will be
https://en.wikipedia.org/wiki/Codec_listening_test
http://wiki.hydrogenaud.io/index.php?title=Hydrogenaudio_Listening_Tests
http://wiki.hydrogenaud.io/index.php?title=Private_Listening_Tests

MPC --standard or --extreme (180~210k) may be good choice. Its very fast and could be better quality than AAC /MP3 256~320k.  Mp3 has some technical limitations and AAC /OGG / opus have not had extensive testing or tuning at high bitrates.
False statements  and giving multiple claims in past without results of  ABX  tests that's a violation of  TOS8.
 


Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #13
True ASIC decoders aren't used anymore. On smartphones there is a highly power efficient DSP core  running a software decoder. This is what people mean by hardware.

On Android devices using Qualcomm hardware the decoder is a hexagon DSP. I'm not sure what Samsung uses in their exynos cores.
Samsung uses very low power Cortex A5 for audio decoding.
http://www.samsung.com/semiconductor/minisite/Exynos/data/Low_Power_Audio_Subsystem_for_Samsung_Exynos_Processor.pdf

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #14
Do audio playback apps use these power saving features and when they are used, can the playback be gapless or support ReplayGain?

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #15
chrome_waves,
Good start will be
https://en.wikipedia.org/wiki/Codec_listening_test
http://wiki.hydrogenaud.io/index.php?title=Hydrogenaudio_Listening_Tests
http://wiki.hydrogenaud.io/index.php?title=Private_Listening_Tests

MPC --standard or --extreme (180~210k) may be good choice. Its very fast and could be better quality than AAC /MP3 256~320k.  Mp3 has some technical limitations and AAC /OGG / opus have not had extensive testing or tuning at high bitrates.
False statements  and giving multiple claims in past without results of  ABX  tests that's a violation of  TOS8.
 


No. Everything I said is spot on and references can be found in the forums historical posts. Enjoy your 32 - 128k world as many people have a lossless archive and use it this way (as it was intended). I don't need abx as I mentioned there may be potential advantages of mpc not that its outright better.

AAC, vorbis , opus have better technical specs than mp3/mpc  but require tuning so that quality scales well at higher bitrate. (See AAC  - emese sample & vorbis HF noise, GT3, AOTUV). Vorbis has had 3rd party work with some success (though AO isn't very keen on high bitrate tuning) , Opus is still new and AAC has many implementations .  MP3 has had many years to mature and fix the worst bugs. There has been interest in mid-high bitrates : --r3mix, --alt-presets, halb27-mods..   The remaining issues cannot be fixed due to formats limits . So it may very well be that mp3 is more abxable yet less annoying at high bitrates whereas something like aac,opus,vorbis  is less abxable yet more annoying in a rare case that a higher bitrate doesn't scale as well as it should.


Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #16
Quote
something like aac,opus,vorbis  is less abxable yet more annoying in a rare case that a higher bitrate doesn't scale as well as it should.
Talk is cheap. Feel free to demonstrate this with real world examples.

"I don't need to provide ABX since I'm using weasel words like may, could and potentially while also providing anecdotal evidence and other logical fallacies." 

Spoken like a true deluded, TOS8-evading placebophile zealot, shadowking.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #17
Quote
something like aac,opus,vorbis  is less abxable yet more annoying in a rare case that a higher bitrate doesn't scale as well as it should.
Talk is cheap. Feel free to demonstrate this with real world examples.

"I don't need to provide ABX since I'm using weasel words like may, could and potentially while also providing anecdotal evidence and other logical fallacies." 

Spoken like a true deluded, TOS8-evading placebophile zealot, shadowking.

Yep I did, lookup emese sample destroying nero AAC @ 350k abxed by myself confirmed by others. Handled extremely well by mpc --standard and even mp3 V2 was better than aac. What is not often abxable on mpc --standard doesn't sound like what aac did and they can be reduced / fixed with --xtreme or --insane.

Also, better isn't always subjective. The OP is interested in mpc.  I said mpc may be better and that can mean objective quality too. How does MP3 spend bits vs mpc ?  @ 200k mpc does better use of them not restricted to 320k frames and not impacted by the sfb21 issue that makes mp3 vbr  bloatfest @ V2 or higher.. though I think recent versions have improved it a bit but by possibly lowering accuracy of HF ?..   Anyway that issue of sfb21 and -Y has never  been fully settled and it only pertain to mp3 so mpc here gets a tick for efficiency (good for portable players).

Also there are many aac encoders using many methods. I understand Apple use some kind of CBR or constrained method @ 256 ~ 320k.  This tells me that its more of a marketing kludge trying to match mp3 than a true VBR mode because they don't / didn't have a stable one. If its true it confirms my theory that interest and tuning a) never happened b) some kind of instability was not worked out.  Because mpc quality 5 ..7 is smaller than some AAC cvbr 256..320 - it should have been AAC more efficient than mpc .

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #18
I said mpc may be better and that can mean objective quality too. How does MP3 spend bits vs mpc ?
That is irrelevant.  We are talking about audible sound quality of lossy compression and the only valid way to gauge it is though testing that controls external biases such as the assumption that one will sound better based on the way you imagine it allocates bits.

If all you have is an example of an outdated codec (Nero) and in unverified speculations about more modern codecs, you really have no business in this disussion.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #19
Yes it matters because almost certainly the OP would be told mp3 V2 and mpc -q5 are generally transparent (hes not interested in 128k). Whether he can abx or not doesn't diminish the fact that mpc would consume less space on the DAP especially for loud HF material.

Theres more examples i can dig up. You don't know that the AAC bug has been fully fixed and old doesn't mean worse especially with todays chaotic software development.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #20
It's now officially a bug with the format because you deemed it as such? No, you're just stoking the fire with more unsubstantiatd paranoia. TOS8 is here to prevent wasting our time going down these rabbit holes.

Regarding mpc and consumption of space, there is no "fact".  Space is only loosely correlated to quality and there is only one proper method of testing to determine quality, despite your empty BS rhetoric about ABX not being necessary.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #21
Do audio playback apps use these power saving features and when they are used, can the playback be gapless or support ReplayGain?

As far as I know the stock Android libraries handle it automatically if you use them for decode. They are gapless but I don't know about replaygain. You should ask someone doing Android development though, I just looked at their source for codec optimization ideas.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #22
No. Everything I said ...
In my opinion greynol has clearly explained the rules. More clear impossible.
There is nothing really to add from my part.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #23
I have already been working on it a little, I chose to use mpc quality 10 (highest)
Using foobar to convert from flac
Hope I made the right decision

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #24
I have already been working on it a little, I chose to use mpc quality 10 (highest)
Using foobar to convert from flac
Hope I made the right decision

MPC is generally transparent ( by design) at --quality 5 and even lower setting --quality 4.x can be very decent for portable use. Going lower than that it starts to show its limits and there are new codecs like aac, opus, vorbis ..

Anyway I was going to tell you before the other made a big noise over nothing:  Do a listening test of several tracks and start at --quality 5.  If you don't care for very high bitrate then --quality 10 without listening test is fine. Anything over --quality 7 is usually considered excessive .