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: Musepack in 2020 (Read 13229 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Musepack in 2020

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?.
Got locked out on a password i didn't remember. :/

Re: Musepack in 2020

Reply #1
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)
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #2
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.
Got locked out on a password i didn't remember. :/

Re: Musepack in 2020

Reply #3
It's 20 years that I'm happy with --radio. Due to storage space abundance these days I use FLAC though.

Re: Musepack in 2020

Reply #4
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!
Listen to the music, not the media it's on.
União e reconstrução

Re: Musepack in 2020

Reply #5
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.
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #6
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?.
Got locked out on a password i didn't remember. :/

Re: Musepack in 2020

Reply #7
sorry, I don't get the meaning, I found this very hard to read.
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #8
[...] 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.
Listen to the music, not the media it's on.
União e reconstrução

Re: Musepack in 2020

Reply #9
[...] 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.
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #10
Yes, we all know of that limitation in particular and TBH, David seemed to have finally thrown the towel 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.
Listen to the music, not the media it's on.
União e reconstrução

Re: Musepack in 2020

Reply #11
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).
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #12
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.

Re: Musepack in 2020

Reply #13
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.

Re: Musepack in 2020

Reply #14
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.
Got locked out on a password i didn't remember. :/

Re: Musepack in 2020

Reply #15
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.

Re: Musepack in 2020

Reply #16
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).


 
Got locked out on a password i didn't remember. :/

Re: Musepack in 2020

Reply #17
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.
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #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).

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.
a fan of AutoEq + Meier Crossfeed

Re: Musepack in 2020

Reply #19
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.



Re: Musepack in 2020

Reply #20
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.


 
Got locked out on a password i didn't remember. :/

Re: Musepack in 2020

Reply #21
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

Re: Musepack in 2020

Reply #22
Spotify has 3 vorbis streams; 96 mobile , 160 free account & 320k premium.

mpc standard can replace them all.

Re: Musepack in 2020

Reply #23
Yep, MPC @ 176k pretty can beat all 3, Could see 240k MPC being premium.
Got locked out on a password i didn't remember. :/

 

Re: Musepack in 2020

Reply #24
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.
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)