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?.
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)
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.
It's 20 years that I'm happy with --radio. Due to storage space abundance these days I use FLAC though.
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!
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.
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?.
sorry, I don't get the meaning, I found this very hard to read.
[...] 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.
[...] 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.
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.
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).
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.
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.
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.
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.
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).
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.
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.
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.
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.
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
Spotify has 3 vorbis streams; 96 mobile , 160 free account & 320k premium.
mpc standard can replace them all.
Yep, MPC @ 176k pretty can beat all 3, Could see 240k MPC being premium.
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.
@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.
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:
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.
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.
Could be Opus since your going from a transform codec to a subband one. It can't reproduce the other stuff without getting confused but when musepack was the source never had issues doing transcodes to other codecs?.
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.
Could be Opus since your going from a transform codec to a subband one. It can't reproduce the other stuff without getting confused but when musepack was the source never had issues doing transcodes to other codecs?.
So you have good experience in transcoding from musepack to other codecs? Which Musepack setting you use?
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.
Could be Opus since your going from a transform codec to a subband one. It can't reproduce the other stuff without getting confused but when musepack was the source never had issues doing transcodes to other codecs?.
So you have good experience in transcoding from musepack to other codecs? Which Musepack setting you use?
Q10
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.
Could be Opus since your going from a transform codec to a subband one. It can't reproduce the other stuff without getting confused but when musepack was the source never had issues doing transcodes to other codecs?.
So you have good experience in transcoding from musepack to other codecs? Which Musepack setting you use?
Q10
How Q10 handles critical samples? Have you tried to ABX any of them?