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 27323 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #25 –
Quote from: greynol on
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.

I don't know . I am talking about acceptable handling of problematic samples. MPC --standard is usually not annoying , abxable problems not very common and 180k .

Theres more cases and I believe this is still an issue:

https://hydrogenaud.io/index.php/topic,6023.msg62524.html#msg62524

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #27 –
Hey guys i've gotta question about an error: on a couple tracks, foobar gives the conversion log with the following info:
3 tracks converted with major problems

song1.mpc - Corrupted FLAC stream

So these errors are corrupted flac stream errors. What does this mean? Should the tracks not be used for listening? I tried with dbpoweramp and I get the same errors on the same tracks.

I have some older mp3 versions of these tracks if it's better not to use the newly created mpc files
 

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #28 –
After doing some reading I learned that the corrupted flac stream error with foobar can be due to different things. I listened to the songs in question but could not hear any abnormalities. Still, I went ahead and used a different source for those problem tracks.

Thanks everyone for all the input and recommendations it's making for interesting reading

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #29 –
The FLAC files giving error messages most likely are corrupted but that message alone isn't enough to know what the problem is. Running such files through File Integrity Verifier component should give more information.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #30 –
Quote from: Case on
Do audio playback apps use these power saving features and when they are used, can the playback be gapless or support ReplayGain?

Interesting question. I see there were a few battery/speed (I guess speed measures CPU cycles) discussions many years ago.

A claim like "sets a new standard for audiophiles" should normally trigger the HA laughing stock, eh?
https://www.qualcomm.com/news/snapdragon/2016/06/02/qualcomm-aqstic-sets-new-standard-audiophiles

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #31 –
Quote from: shadowking on
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.

[…]

Everything I said is spot on and references can be found in the forums historical posts. […]

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 . 

I'm a bit surprised—and disappointed— to read this on HA.org nowadays. It was perfectly accepted in the first years of HA.org. But I far as I know, Musepack didn't improve quality since ~2003 when Frank Klemm worked on the encoder. On the meantime there were a continuous activity on LAME MP3, AAC (Apple) and Vorbis.

You mentioned HA archives. I remind to everyone my most difficult listening test I made at ~180 kbps on non-critical samples in 2005:

—source—
Musepack was clearly behind Vorbis at similar bitrate. It was twelve years ago, Musepack didn't improve while the other did (and in the meantime Opus appeared).

I also remind the existence of a serious flaw that affected (and still affects?) MPC and MPC only while encoding very quite samples which are either replaygained or played at high volume. The demonstration is now gone but the discussion is still —there—.

Was it corrected since? It doesn't seem so according to the descriptions I can read at musepack.net.

While MPC is still perfectly usable nowadays the format has lost to my ears all its magic more than ten years ago. It shines on some specific samples (pure pre-echo stuff) but on regular music I found it less impressive than Vorbis during careful and really hard listening comparison (which I probably can't perform again these days). I wouldn't use it at first place and rather go for AAC (Apple), Vorbis and maybe Opus.

I also insist: the listening test I mention is partially obsolete and is also based on my own sensitivity. AAC improved a lot in the meantime. But MPC didn't. It's a dead star... you can still see the light coming from but it's gone. Its excellent reputation come from days that don't exist either. There are better formats today.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #32 –
Quote from: guruboolez on
On the meantime there were a continuous activity on LAME MP3, AAC (Apple) and Vorbis.

You forgot Opus (which is still being worked on and is according to the listening tests here on HA one of the best codecs nowadays).

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #33 –
Quote from: butrus on
You forgot Opus (which is still being worked on and is according to the listening tests here on HA one of the best codecs nowadays).
Not really:
Quote from: guruboolez on
It was twelve years ago, Musepack didn't improve while the other did (and in the meantime Opus appeared).
:)

As far as I know, Opus excellent quality is acknowledged on HA.org at low bitrate only. For high bitrate do we have enough tests and report to consider it as excellent as well?

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #34 –
Quote from: greynol on
2003?!?

Modern times:
https://hydrogenaud.io/index.php/topic,109448.msg901009.html#msg901009
https://hydrogenaud.io/index.php/topic,77128.msg674479.html#msg674479
https://hydrogenaud.io/index.php/topic,112572.0.html
https://hydrogenaud.io/index.php/topic,102429.0.html

Theres still no major problem with musepack . As I pointed out issues at --quality 5 are 'contained' and usually solved or benign by quality 6 or 7 . OTOH posts confirm that issues persist in AAC and vorbis even @ 320k or more. Read other testers comments and they do not disagree with me a few years back.  Halb27 had similar impression although he thought there may be some possible issue.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #35 –
The 180k test of 2005 still suggest that musepack was/is excellent and had no major issues. Stranger the previous one of 2004 found it more favorable. Either in 1 year the other improved a lot or mpc regressed.. Either way all the data suggest to excellent performance in all tests against other codecs even in 128k segment. The low volume ringing issue is probably limited to certain situations and I think there was a switch to improve such samples. Quality has not been worked on since 2003 as pointed out although SV8 improves overall bitrate to be closer to the 1.14 encoder. Its possible that the SV8 format has some positive aspects inc sound quality.. Actually SV7 is still a fully supported format although not developed anymore.

This 'activity' by other codecs is more like bugfixes and incremental improvements rather than major ones. Major ones can also bring in regressions.  This would make them not too unlike musepack. Except for Opus which is newer expected to have more radical changes.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #36 –
I support shadowking's opinion that mpc is a mature codec which sound quality wise is still relevant today for the intended bitrates.

Roughly speaking other than for low to moderate bitrates it is hard to find hard arguments to prefer one good lossy encoder over another one simply because each of them provides great quality at higher bitrates for nearly every kind of music for nearly every listener. I remember the last public mp3 listening test @128 kbps which showed up very good quality even for this old codec at this moderate bitrate for most of the encoders tested.
Care must be taken if a person is especially sensitive towards certains aspects (as is /mnt for pre-echo; and in this case mpc is a favorable codec).

I dislike apreciating development for itself.
lame3995o -Q1.7 --lowpass 17

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #37 –
The Musepack article on Wikipedia links to http://soundexpert.org/encoders-128-kbps . Blind testing on the basis of "download a random and upload your rating", but I have no idea when the majority of the results are from. But the issue is not whether Musepack is any good, but how it compares to the relevant alternatives (for Android playback, in this thread) - and largely, disregarding very odd demands.

-> Compatibility? No way. (If you transcode from WavPack or Monkey's and consider APE tags a compatibility thing, then that is an odd demand methinks.)
-> You use MPC elsewhere? Odd demand, like it or not.
-> Sound quality? TOS#8.
-> Battery efficiency? Show me the numbers.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #38 –
There were other 128k tests done here - see 'roberto 128 multi format..' . MPC was always at the top or close.

On the PC compatibility is a non-issue given many player support it native or via a plugin. Several players can be installed in 'portable' mode thus giving you mpc playback without needing to install anything.
On android the PowerAMP app and some others play it OOTB with replaygain / gapless - stuff that Google most likely doesn't support in their 'relevant' codecs. At least MPC and vorbis were designed gapless unlike mp3  / aac and this could be an issue - I read one poster here confirmed it in the threads I posted..   IOS - I don't have experience though I read there are similar players.

I have tested playback in Poweramp and everything went fine though I will give it another spin soon. The phone is an old galaxy S3. CPU was 12 % flac around 10 % , mp3 20%, wv lossy -x4 17%..FYI even monkeys audio played smoothly up to the high c3000 setting.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #40 –
Musepack q6 (or higher) is the best choice.
1. There is no pre-echo
2. Battery economy

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #41 –
Quote from: John Silver on
2. Battery economy

Are there measurements to back this up? A lot of modern devices do MP3 decoding natively in extremely power-efficient ways.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #42 –
Quote from: KozmoNaut on
Quote from: John Silver on
2. Battery economy

Are there measurements to back this up? A lot of modern devices do MP3 decoding natively in extremely power-efficient ways.

Are there really any such things as truly hardware MP3 encoders or decoders? Aren't they all specialized microprocessors or DSP executing microcode? Real world examples, please.

Here's an example: http://www.vlsi.fi/en/products/vs1063.html.  "VS1063 - MP3 / Ogg Vorbis Encoder and Audio Codec Circuit"  Obviously a specialized microcomputer with firmware on a chip. Here is the principles of operation manual including instruction set documentation. http://www.vlsi.fi/fileadmin/manuals_guides/vsdsp4_ump.pdf

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #43 –
Quote from: KozmoNaut on
Quote from: John Silver on
2. Battery economy
Are there measurements to back this up? A lot of modern devices do MP3 decoding natively in extremely power-efficient ways.
If you don't use a special low power DSP for certain format this is easy to test with the mobile foobar2000 that includes decode speed tester. The faster a format is to decode the less power its realtime playback requires from the CPU.

Note that mobile foobar2000 on Android for example can't utilize the supposed low power DSP method. It would mean handing over the playback for the OS and it can't do any of the features foobar2000 requires.

PS: I assume Google's Play Music uses the low-power DSP method for playing MP3s. It seems to fail a basic gaplessness test. Tested on a Nexus 6P running Android 7.1.2 beta.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #44 –
Most importantly, the quality of the Musepack is 192 kbps higher than that of the MP3 at the same speed.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #45 –
Quote from: Arnold B. Krueger on
Are there really any such things as truly hardware MP3 encoders or decoders? Aren't they all specialized microprocessors or DSP executing microcode? Real world examples, please.

I don't have any on hand, but early MP3 players certainly used dedicated hardware to decode MP3, such as the STA013: https://www.pjrc.com/mp3/sta013.html

Some still do, like the cheap Chinese MP3 player in my car. Very basic thing, only plays files in sequence from an SD card, no shuffle or any other features.

It's a dedicated chip, but maybe you would just call it a specialized microprocessor executing microcode. If that's your criteria, yes there are no 100% hardware decoders. I was thinking of dedicated chips running dedicated code.

But yes, what I meant is that modern smartphones etc. use power-efficient DSPs, and if a given codec is not able to be hardware decoded for whichever reason (not possible, not yet implemented, DSP cannot do it), it will be much less efficient to use.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #46 –
Complexity doesn't matter anymore these days.

I've tested relatively high complexity formats like  HE-AACv1(64 kbps) and Opus (128 kbps) pure software decoding on economic smarthpone with quad-core Cortex A7 (28 nm). It was on Rockbox Android version (I think it's still alpha).  Got 35+ hours of battery life! Of course, the test was done with display turned off. 
35 hours. It means 5 hours of music listening each day during whole week. Ridicuously right?

MP3, AAC, Musepack, Vorbis or whatever, your device will still consume considerably more power for display, wi-fi/LTE modem, background applicacionts, OS stuff, DAC and AMP themselves.

Musepack can be 1000% more power efficient than HE-AAC  however it doesn't translate in a better battery usage in real life.

 

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #47 –
Quote from: KozmoNaut on
Quote from: Arnold B. Krueger on
Are there really any such things as truly hardware MP3 encoders or decoders? Aren't they all specialized microprocessors or DSP executing microcode? Real world examples, please.

I don't have any on hand, but early MP3 players certainly used dedicated hardware to decode MP3, such as the STA013: https://www.pjrc.com/mp3/sta013.html

Some still do, like the cheap Chinese MP3 player in my car. Very basic thing, only plays files in sequence from an SD card, no shuffle or any other features.

It's a dedicated chip, but maybe you would just call it a specialized microprocessor executing microcode. If that's your criteria, yes there are no 100% hardware decoders. I was thinking of dedicated chips running dedicated code.

But yes, what I meant is that modern smartphones etc. use power-efficient DSPs, and if a given codec is not able to be hardware decoded for whichever reason (not possible, not yet implemented, DSP cannot do it), it will be much less efficient to use.

Actually, it is a chip with secrets. I couldn't tell enough from the doc I uncovered for it to tell much one way or the other.

However, I heartily thank you for the reference to investigate,,

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #48 –
Codec power consumption seems to be more complex to estimate than just checking their decoding speed.

I used mobile foobar2000 on a Nexus 10 tablet to benchmark single threaded decoding speed of various codecs and compared battery use between the slowest lossy format and the fastest. Slowest turned out to be Opus and the fastest was AAC. With the album I tested Opus decoding speed was 108 times realtime speed and AAC was 330 times realtime speed.

I didn't test how long the battery can last until it's empty as that would have taken days. I played both formats under the same conditions for 8 hours 38 minutes and checked the battery level reported by the OS afterwards.

With AAC foobar2000 had used 9% of battery and remaining battery level was at 88%.
With Opus foobar2000 battery consumption was 7% and battery capacity was at 91%.

Perhaps Opus won the test because its bitrate was almost 50% lower than the AAC files. Average for the AACs was 127 kbps and for Opus 67 kbps.

Re: Compressing Lossless to Lossy - Codec Recommendations ?

Reply #49 –
Case, interesting and actually useful data.

That's why I prefer to use real life tests. Benchmarking of decoding speed isn't just representative of battery usage.
And a lot of people have already labeled HE-AAC and Opus formats as "slow" and "power hungry". And it's simply not case.

Probably higher bitrate consumes more power because of reading more data  from microSD and loading it to memory.