HydrogenAudio

Lossy Audio Compression => MPC => Topic started by: ani_Jackal3 on 2020-09-07 06:50:29

Title: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-07 06:50:29
Been adding music to my Phone, I really love how competitive --Standard is to 160k modern codecs & 192k MP3. Nice to have actual transparency on complex electronic since I've noticed they seem to cry when used?.
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-07 10:32:29
It's not really transparent by default, I've found it needs at least 2 workarounds:
1) need to adjust ATH per track using option ltq_gain based on track loudness (not really viable to do by hand, because each track needs a different value, so you'd need to script that; I wrote it already btw, can upload if someone's interested), otherwise it will delete too much stuff from very quiet tracks
2) it's easily ABXable on a "killer" sample "Fighter_Beat_Loop" even at maximum quality preset (and this sample sounds quite similar to sounds which can be found in some music genres), and I've found only 1 way to work around that (add `--nmt 18` option) which also raises bitrate quite a lot, making it harder to say it's competitive with modern codecs)
Title: Re: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-07 11:08:44
I've never had any issue where i need to touch the extra settings, I just remember doing a ABX on that sample i couldn't tell even with non --nmt Q5. Yet with artists like The Rita - Rack, The Haters - Nikumu San & Untitled from Nikumu 2007 also by The Haters it sounds fine with them too, Yet with Vorbis it fails hard.  Here some 30sec samples both Wav & 160kbps Vorbis as the worst case.
Title: Re: Musepack in 2020
Post by: rutra80 on 2020-09-07 18:36:37
It's 20 years that I'm happy with --radio. Due to storage space abundance these days I use FLAC though.
Title: Re: Musepack in 2020
Post by: includemeout on 2020-09-09 02:13:33
It's not really transparent by default, I've found it needs at least 2 workarounds:
1) need to adjust ATH per track using option ltq_gain based on track loudness (not really viable to do by hand, because each track needs a different value, so you'd need to script that; I wrote it already btw, can upload if someone's interested), otherwise it will delete too much stuff from very quiet tracks
2) it's easily ABXable on a "killer" sample "Fighter_Beat_Loop" even at maximum quality preset (and this sample sounds quite similar to sounds which can be found in some music genres), and I've found only 1 way to work around that (add `--nmt 18` option) which also raises bitrate quite a lot, making it harder to say it's competitive with modern codecs)
 
 

After learning about the level o contrivance you have to resort to, all I could infer is that Musepack, though still viable for many people - well into our current days, just didn't work for you as a lossy VBR CODEC should:
i.e, set it up once or twice and forget about it! - not on a per-song basis!
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-09 15:42:43
I ended up still using it (with that script which ideally shouldn't be needed) because storage limits are not as tight as they used to be, and other lossy codecs have some other problematic samples for which I couldn't find ways to fix. (And I also prefer to be able to encode both 44.1 kHz and 48 kHz content without resampling, because resampling adds too much complexity for gapless encoding of a lot of stuff at once)
There's also LossyFLAC option, but it uses even more bits to achieve transparency everywhere.
Title: Re: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-09 16:52:38
I ended up still using it (with that script which ideally shouldn't be needed) because storage limits are not as tight as they used to be, and other lossy codecs have some other problematic samples for which I couldn't find ways to fix. (And I also prefer to be able to encode both 44.1 kHz and 48 kHz content without resampling, because resampling adds too much complexity for gapless encoding of a lot of stuff at once)
There's also LossyFLAC option, but it uses even more bits to achieve transparency everywhere.

If your using 384kbps with Lossywav then up the ANS/DNS settings. MPC already on few samples goes into lossless mode(256 ~ 1200kbps), Which is why I'm V2 ~ V1 Lame with Wavpack lossy at 480kbps(DNS). Since my DAP I have as a back up only supports AAC/MP3 & i can't tell V2 either(99.5%), AAC/Ogg seem iffy with Ambient yet Lame fine?.
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-09 16:57:36
sorry, I don't get the meaning, I found this very hard to read.
Title: Re: Musepack in 2020
Post by: includemeout on 2020-09-10 16:54:38
[...] other lossy codecs have some other problematic samples for which I couldn't find ways to fix.[...]
 
 Did you give Wavpack hybrid a try? I mean, at least with my sig's settings I was unable to hear anything on even samples as problematic as Eig.
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-11 11:56:04
[...] other lossy codecs have some other problematic samples for which I couldn't find ways to fix.[...]

 Did you give Wavpack hybrid a try? I mean, at least with my sig's settings I was unable to hear anything on even samples as problematic as Eig.
Yes.
1) it has no true VBR mode (based on a quality metric), so it's always going to be a guessing game and allocating too much bits sometimes.
2) I remember there were some samples with high pitched tones where it requires way too high settings to become transparent
I should probably try again, but until 1) changes, I don't think it's going to do much better than LossyFLAC and I... don't really have a lot of free time and mental power to do all the listening tests again.
Title: Re: Musepack in 2020
Post by: includemeout on 2020-09-11 15:07:07
Yes, we all know of that limitation in particular and TBH, David seemed to have finally th (https://hydrogenaud.io/index.php?topic=100029.msg828971#msg828971)rown the towe (https://hydrogenaud.io/index.php?topic=100029.msg828971#msg828971)l (https://hydrogenaud.io/index.php?topic=100029.msg828971#msg828971) on that several years ago.

But
IMHO, that is still a relatively small price to pay if one wants, like in your specific case, to put one's mind at rest (something that, and this thread has seemed to shown it, is not the case with formats as established and mature as Musepack for such specific cases). Okay, still using double the storage space of other lossy CODECs (set at very HQ settings) - but half the space that lossless would take up!

And although we still have storage getting cheaper by the day, it's another story now if you have buy now, say, a 512GB SD card instead of much cheaper 128 or 256GB one, assuming we're inherently talking portable here.
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-11 17:52:18
well, for putting mind at rest LossyFLAC should be better because it has a well defined target of quality in well defined metrics (minimum signal to noise ratio over certain ranges) so you can pick a specific quality level and be done; that's unlike WavPack (you choose bitrate and never really know which quality it will be able to achieve within this bitrate).
Title: Re: Musepack in 2020
Post by: shadowking on 2020-09-13 11:59:39
well, for putting mind at rest LossyFLAC should be better because it has a well defined target of quality in well defined metrics (minimum signal to noise ratio over certain ranges) so you can pick a specific quality level and be done; that's unlike WavPack (you choose bitrate and never really know which quality it will be able to achieve within this bitrate).

But, Only at higher than 400k . In which case, Wavpack error margin is expected to
be non issue if we match lossywav top settings vs wavpack 500k -hx4.

The objective quality of wavpack per bitrate is higher than lossy wav according to
bryant. lossywav moves noise in 6db steps, While wavpack can do so in infinite steps.

Also,  Another direction wavpack does better in the low end bitrate .  One can use
200k segment  -particularly 256k while this is not well tested in lossywav.
Title: Re: Musepack in 2020
Post by: shadowking on 2020-09-13 12:47:36
musepack is still a good option for well tuned parameters
and reasonably lean bitrates.

The other codecs like opus, vorbis, aac have VBR but simply throw
the 'use higher Q value for HQ and lower for lower quality etc..'
as well as things like CVBR vs VBR debates.

It seems a tuned efficient 'set and forget' system was never considered.
it may well be that this is not significant but I still think there
is an advantage to musepack .   mpc @ standard and extreme is much leaner
than 'new normal' 256 ~ 320k of other codecs.
Title: Re: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-13 20:23:39
musepack is still a good option for well tuned parameters
and reasonably lean bitrates.

The other codecs like opus, vorbis, aac have VBR but simply throw
the 'use higher Q value for HQ and lower for lower quality etc..'
as well as things like CVBR vs VBR debates.

It seems a tuned efficient 'set and forget' system was never considered.
it may well be that this is not significant but I still think there
is an advantage to musepack .   mpc @ standard and extreme is much leaner
than 'new normal' 256 ~ 320k of other codecs.

Yeah the other codecs are a mess, Either patchy transparency or need at least 5 custom switches to sound fine. Because the devs wave a white flag when it dies on something, Yet MPC @ 176k to my ears is 100% even on pure tonal & harsh noise samples despite being a pure subband codec.
Title: Re: Musepack in 2020
Post by: rutra80 on 2020-09-14 00:09:51
Beside transparency there's also a question of artifacts. I find MPC and lossyWAV artifacts tolerable. I hate MP3's and most other codecs' pre-echo and ringing artifacts.
Title: Re: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-14 10:42:53
Beside transparency there's also a question of artifacts. I find MPC and lossyWAV artifacts tolerable. I hate MP3's and most other codecs' pre-echo and ringing artifacts.

Vorbis to me seems to collapse sooner than Lame/AAC do. Anything like the Autechre sample from here, Vorbis can't reproduce it without added noise to it it needs Q9(320k) to fix it. Yet on the same sample MPC sounds transparent at 178k average. Kongara by Merzbow on Vorbis there added noise within 96 ~ 275kbps, That dosen't go away until I try 350kbps(Q9.2).


 
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-14 11:04:53
Beside transparency there's also a question of artifacts. I find MPC and lossyWAV artifacts tolerable. I hate MP3's and most other codecs' pre-echo and ringing artifacts.
The main thing about transparency is that, by definition, if it's transparent, you can't hear the difference, so the type of this difference doesn't really matter.
Or do you mean, the occasions where it accidentally misses the mark and is not being transparent? Then yeah, that's a good point.
Title: Re: Musepack in 2020
Post by: magicgoose on 2020-09-14 11:09:29
well, for putting mind at rest LossyFLAC should be better because it has a well defined target of quality in well defined metrics (minimum signal to noise ratio over certain ranges) so you can pick a specific quality level and be done; that's unlike WavPack (you choose bitrate and never really know which quality it will be able to achieve within this bitrate).

But, Only at higher than 400k . In which case, Wavpack error margin is expected to
be non issue if we match lossywav top settings vs wavpack 500k -hx4.
But can it be proved in general? I don't think so.
In contrast, it's trivially ensured with LossyWAV, because the S/N ratios are the original constraint chosen by you.
If we're really talking about putting mind at rest, then the presence of proof beats the absence of proof.
Title: Re: Musepack in 2020
Post by: shadowking on 2020-09-14 12:11:53
well, for putting mind at rest LossyFLAC should be better because it has a well defined target of quality in well defined metrics (minimum signal to noise ratio over certain ranges) so you can pick a specific quality level and be done; that's unlike WavPack (you choose bitrate and never really know which quality it will be able to achieve within this bitrate).

But, Only at higher than 400k . In which case, Wavpack error margin is expected to
be non issue if we match lossywav top settings vs wavpack 500k -hx4.
But can it be proved in general? I don't think so.
In contrast, it's trivially ensured with LossyWAV, because the S/N ratios are the original constraint chosen by you.
If we're really talking about putting mind at rest, then the presence of proof beats the absence of proof.

There is some limited evidence and that VBR isnt always a panacea.
In earlier lossywav version my first test using normal music cd and VBR 'portable'
@ 350 k
https://hydrogenaud.io/index.php?topic=77042.msg683470#msg683470

Other posts you can look back. Users Den, Halb27, porcupine, bryant and myself. There are
confirmed reports of people distiguishing 256, 320k , rarely 400k but not the 500k area.


Title: Re: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-14 14:12:08
musepack is still a good option for well tuned parameters
and reasonably lean bitrates.

The other codecs like opus, vorbis, aac have VBR but simply throw
the 'use higher Q value for HQ and lower for lower quality etc..'
as well as things like CVBR vs VBR debates.

Didn't the MPC devs tune the 160 ~ 320k area only?, with 176kbps getting most of the effort. The biggest issue i noticed on some harder samples mpc @176k, Will pump out 230 ~ 850kbps to aid on transparency. But on those 3 codecs they mostly don't do that unless your at 256kbps & some decoders fail when it reaches 500kbps+.

On Opus @96k with ambient content I've seen it reach ~190kbps, Yet MPC/Lame at 175kbps will average 100kbps +/-. Noticed too when Lame V5 is done on a public listening test.


 
Title: Re: Musepack in 2020
Post by: shadowking on 2020-09-14 16:09:32
musepack is still a good option for well tuned parameters
and reasonably lean bitrates.

The other codecs like opus, vorbis, aac have VBR but simply throw
the 'use higher Q value for HQ and lower for lower quality etc..'
as well as things like CVBR vs VBR debates.

Didn't the MPC devs tune the 160 ~ 320k area only?, with 176kbps getting most of the effort. The biggest issue i noticed on some harder samples mpc @176k, Will pump out 230 ~ 850kbps to aid on transparency. But on those 3 codecs they mostly don't do that unless your at 256kbps & some decoders fail when it reaches 500kbps+.

On Opus @96k with ambient content I've seen it reach ~190kbps, Yet MPC/Lame at 175kbps will average 100kbps +/-. Noticed too when Lame V5 is done on a public listening test.


 

I believe 'standard' profile was the main tuning .  The higher settings are all based on that too.

Yes, you can expect 176k avg. My experience with bitrate is similar. Portishead etc will be around 100k
and transparent. Heavy metal 160..180k and transparent. Thats pretty cool.
Mp3 APS / V2 would give 250k on metal, maybe 160..180k on portishead
Title: Re: Musepack in 2020
Post by: shadowking on 2020-09-14 16:25:45
Spotify has 3 vorbis streams; 96 mobile , 160 free account & 320k premium.

mpc standard can replace them all.
Title: Re: Musepack in 2020
Post by: ani_Jackal3 on 2020-09-14 18:49:17
Yep, MPC @ 176k pretty can beat all 3, Could see 240k MPC being premium.
Title: Re: Musepack in 2020
Post by: synclagz on 2020-09-15 07:25:57
According to this reencoding listening test
https://hydrogenaud.io/index.php?topic=119424.0

Enola sample was not transparent even at musepack Q8 setting, so probably need Q9 or 10 to mitigate this issue.
However, I'm not sure if this artifact, that guruboolez noticed, is introduced by musepack as source or opus at 64k.
Title: Re: Musepack in 2020
Post by: [JAZ] on 2020-09-15 21:26:23
@synclagz : Don't use the reencoding test as a gauge for the source encoders.
Such a test is in regards to the interaction of two codecs, and just like reencoding mp3 to mp3 many times is worse than mp3 to mp4,  that does not make the initial mp3 worse than the mp4, but rather the interaction of mp3 with an mp3 to be bad.
Title: Re: Musepack in 2020
Post by: includemeout on 2020-09-18 20:12:00

It's not really transparent by default, I've found it needs at least 2 workarounds:
1) need to adjust ATH per track using option ltq_gain based on track loudness (not really viable to do by hand, because each track needs a different value, so you'd need to script that; I wrote it already btw, can upload if someone's interested), otherwise it will delete too much stuff from very quiet tracks
2) it's easily ABXable on a "killer" sample "Fighter_Beat_Loop" even at maximum quality preset (and this sample sounds quite similar to sounds which can be found in some music genres), and I've found only 1 way to work around that (add `--nmt 18` option) which also raises bitrate quite a lot, making it harder to say it's competitive with modern codecs)
 
 


magicgoose, as you username is highlighted on the Musepack forum lately as their latest user addition, I wonder if you came across this post (https://forum.musepack.net/showthread.php?t=672) by Frank Klemm from which I quote the following as, IMO, fits the bill perfectly regarding your own adjusting of Musepack's quality settings:

Quote
Simply, there's usually a very high chance that using --quality 6 for example would give you better quality at a similar average bitrate to the one you got with the manually "tweaked" --quality 5.
 
 

That at least makes sense to me as I've been a relatively happy bunny with --quality 6 for the times (non electronic music mainly) I'm not using Wavpack hybrid.
SimplePortal 1.0.0 RC1 © 2008-2021