How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Topic: How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis? (Read 72005 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #25 – 2013-08-30 20:59:29

I did a lot more listening tests with Musepack. The very good impression remained, but finally I managed to ABX a quiet part of Ravel's Bolero at standard quality and with volume strongly turned up. I also think trumpet and harp40_1 aren't perfect. But all these 'issues' aren't really significant to me in practical listening situations. I also tried quality 6 with Bolero, trumpet, and harp40_1. trumpet and Bolero were fine to me, but with harp40_1 I got at least an 8/10 result at quality 6. I also compared the harp40_1 Musepack quality 6 result with that of lame3100l --bCVBR 266, and both encodings were of an equally good quality to me (but Musepack quality 6 takes only 206 kbps on average for my usual test set of various pop music).

My impression is that Musepack quality 5 or 6 provides a consistent very high quality, as shadowking said. Because of this consistency I'd prefer it like him over mp3 or aac used with a corresponding or even somewhat higher average bitrate.
But I've made up my mind to stick with mp3 as long as I don't run into storage space problems (the probability for this has increased from zero to a somewhat higher percentage since I've had to change my smartphone).

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #26 – 2013-08-31 10:49:51

Quote from: darkbyte on 2013-08-28 19:32:17

I wonder how Musepack's subbands align with SBC's subbands. I'm currently using LossyFlac extraportable to provide as slightly modified audio file as possible to SBC encoding to achieve better quality but maybe because mpc is based on mp2 and SBC is based on mp1 it might be a good choice aswell with half the bitrate.

I was wandering myself about the same. I was looking for a SBC free source code, there was some oss project back in time, but I couldn't find it anymore.
Anyway, I cannot code in C/C++ but maybe somebody from Musepack Developer team can try to implement it, maybe as addition to a next streaming version (because the current SV8 is already finalized)?

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #27 – 2013-09-02 18:01:33

I cant believe musepack isnt as compatible as it should be, I encoded using q6 and the quality is great, i would be more than happy to use this if compatibility was better.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #28 – 2013-09-02 23:33:27

Quote from: halb27 on 2013-08-30 20:59:29

[..] finally I managed to ABX a quiet part of Ravel's Bolero at standard quality and with volume strongly turned up.[..]

But I've made up my mind to stick with mp3 as long as I don't run into storage space problems.

I remember that the issue of very quiet sound, turned up after encoding, was brought to Frank Klemm's attention (long ago). It had something to do with threshold of hearing (ATH). AFAIK this is a fixed value (parameter, also set by --quality) during a Musepack encode. It doesn't vary with the sound level. I understood the idea was that if it would, it would cause a (huge) bit rate bloat.

More than 10 years ago I was actively using Musepack, at some point though, new devices came across my path that could not play .mpc. Although I didn't abandon my older Musepack encodes, I encode nowadays everything with Lame or Flac (or lossyFlac). Just like I stopped using WavPack and TAK. All very good but, I'm sorry to say, not popular enough to become widely implemented in playback devices.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #29 – 2013-09-03 13:26:59

Quote from: GeSomeone on 2013-09-02 23:33:27

Quote from: halb27 on 2013-08-30 20:59:29
[..] finally I managed to ABX a quiet part of Ravel's Bolero at standard quality and with volume strongly turned up.[..]

But I've made up my mind to stick with mp3 as long as I don't run into storage space problems.
I remember that the issue of very quiet sound, turned up after encoding, was brought to Frank Klemm's attention (long ago). It had something to do with threshold of hearing (ATH). AFAIK this is a fixed value (parameter, also set by --quality) during a Musepack encode. It doesn't vary with the sound level. I understood the idea was that if it would, it would cause a (huge) bit rate bloat.
[..]

Actually, you can control some ATH parameters, but the 'adaptive threshold in quiet' is switched on by default:

Code: [Select]

==ATH/Bandwidth settings==
  --bw x           maximum bandwidth in Hz (dflt:  0.0 kHz)
  --minSMR x       minimum SMR of x dB over encoded bandwidth (dflt: 1.0)
  --ltq xyy        x=0: ISO threshold in quiet (not recommended)
                   x=1: more sensitive threshold in quiet (Buschmann)
                   x=2: even more sensitive threshold in quiet (Filburt)
                   x=3: Klemm
                   x=4: Buschmann-Klemm Mix
                   x=5: minimum of Klemm and Buschmann (dflt)
                   y=00...99: HF roll-off (00:+30 dB, 99:-30 dB @20 kHz
  --ltq_gain x     add offset of x dB to chosen ltq (dflt: +0.0)
  --ltq_max x      maximum level for ltq (dflt: 76.0 dB)
  --ltq_var x      adaptive threshold in quiet: 0: off, >0: on (dflt: 1)
  --tmpMask x      exploit postmasking: 0: off, 1: on (dflt: 1)

Disabling the adaptive ATH it actually increase the result bitrate a bit (about 0.6% in my case).
However, you can try --ltq 250 for 'even more sensitive threshold in quiet (Filburt)' (in my case that yielded a bitrate increase of about 2%) and even add an offset with --ltq_gain.

@halb27
Would you mind sharing the fragment you've successfully ABX-ed?

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #30 – 2013-09-03 13:48:21

Here it is.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #31 – 2013-09-05 17:56:29

I have switched from MPC to AAC at one point because none of my feature phones supported MPC. I'm talking 200-250kbit encodings for both formats. I would have no problem sticking with MPC if it had wider support (audio quality wise). It's truly an amazing codec.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #32 – 2013-09-06 11:58:41

I listened a bit more to Musepack encodings with my Stax electrostatic headphone. No problem samples, just regular music. My feeling is that music is kind of more 'vivid' than when using mp3.
Feelings can be based on expectation of course, instead of audible difference. So I tried to ABX the difference last night.
I failed with the first song I tried, so I looked up my collection for a very high quality track. I ended up with Rickie Lee Jones' 'Under the Boardwalk' from the album 'Girl At Her Volcano'.
I ABXed Musepack --quality 7 against lame3100l --bCVBR 266. I did not get a real positive ABX result, but at least a 9/12 (7.3% guessing), and it took me 9 minutes. I also tried a somewhat stronger lame setting with a similar result. -V0 --cvbr 0 however was fine to me last night. By then I was pretty tired, so I repeated the -V0 --cvbr 0 test this morning, with a 8/11 result (11.3% guessing), which took me 10 minutes.

Well, these aren't proper ABX results, and the differences are subtle of course. For -V0 --cvbr 0 the differences are negligible to me (if they ever exist). But with my standard lame setting I'm not so happy compared to the quality of Musepack --quality 7, especially as the sample tried isn't a problem sample.
So I think I will turn to Musepack as I can use it with all my devices.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #33 – 2013-10-31 15:36:06

All my mobile library is in Musepack format.
Initially I worked with quality 'Extreme' and 'Braindead' (--quality 7 and

, but after a few ABX tests I could not distinguish the quality 'Standard' (--quality 5) from the original source.
Since then I have my songs converted in --quality 5.15, 5.25 and 5.35.
The result obtained with --quality 5.35 is almost exactly equal in size and bitrate to QAAC tvbr91 q2.

PS: BASS library for Android from un4seen.com released a MPC plugin. The latest Aimp beta for Android has included support for Musepack

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #34 – 2013-10-31 15:47:20

Quote from: larryfine on 2013-10-31 15:36:06

The result obtained with --quality 5.35 is almost exactly equal in size and bitrate to QAAC tvbr91 q2.

This doesn't mean anything in terms of sound quality.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #35 – 2013-10-31 19:12:26

Quote from: eahm on 2013-10-31 15:47:20

Quote from: larryfine on 2013-10-31 15:36:06
The result obtained with --quality 5.35 is almost exactly equal in size and bitrate to QAAC tvbr91 q2.

This doesn't mean anything in terms of sound quality.

Okay,
but I'm not comparing size / bitrate vs quality or stating any other kind.
To my ears MPC --quality 5.35 quality has the same transparency that AAC -V 91 -q 2, most likely would be unable to distinguish both in ABX test.
What inclines me to Musepack is reliability and good performance on my device, saving about 3 ~ 5% of resources.
I also had one or the other problem with gapless playback using AAC, it never occurred with MPC.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #36 – 2013-12-04 23:19:25

I've converted my collection to mpc, and I'm very happy with the --quality 7 result.

There's one thing though: clipped material tends to sound worse than the original. I ABXed the difference for Rickie Lee Jones' track 'Cycle'.
This Audacity procedure applied to the original did the trick so far in my cases:
a) amplify by -0.4 dB
b) select the clipped range(s) and apply ClipFix (clipping threshold: 85%).
The modified source material sounds better than the original in the clipped regions, and the mpc encodings were fine to me.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #37 – 2013-12-05 04:30:51

Quote

clipped material tends to sound worse than the original

Quote

My wife and I noticed the same thing on a recent road trip where we were playing a shuffle on a Rockbox'd Sansa Clip Zip with Replaygain applied. A Paul Simon "Graceland" track was immediately followed by a Black Keys "El Camino" track. The Keys track sounded awful by comparison; which was a bit of a shock considering the low fidelity of the fm transmitter we were using. Throughout the trip, we noticed this on several more occasions. I made a mental note that it seemed to occur on songs with what I thought were "hot" masters. After getting home, I checked the DR database on several of the offending tracks, and all were notably "hot". Subsequently, I abandoned the MPC format because it seemed like too much work to sort through my music catalog for "hot" masters for which I would avoid the MPC format. I should note that I didn't bother to abx any of the tracks; the road trip experience coupled with the DR database was enough circumstantial evidence for me to attribute the problem to clipped music being more noticeably bad when with MPC with Replaygain applied. At any rate, I went back to my aac, Lame, and Vorbis files for my lossy music.

Thanks for the apparent solution Halb27, but it still seems like too much time and work for me.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #38 – 2013-12-05 08:09:29

MPC runs into "internal clipping" every now and then. You could see it if you were using the command line encoder manually.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #39 – 2013-12-05 14:48:49

Quote from: LedHed8 on 2013-12-05 04:30:51

Quote
clipped material tends to sound worse than the original
Quote

... Subsequently, I abandoned the MPC format because it seemed like too much work to sort through my music catalog for "hot" masters for which I would avoid the MPC format. ...

I guess I'll end up like you. But after re-encoding my entire collection (no problem) and assigning reasonable RG values (a big issue because many tracks need adjustment from the calculated RG values) I still give mpc a try.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #40 – 2013-12-05 14:51:10

Sorry, posting error on my side.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #41 – 2013-12-05 15:15:07

Quote from: Martel on 2013-12-05 08:09:29

MPC runs into "internal clipping" every now and then. You could see it if you were using the command line encoder manually.

I tried this (using version 1.30.0 SV8), but didn't see a corresponding info.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #42 – 2013-12-05 16:31:31

You can always apply ReplayGain (or just a fixed gain reduction) before encoding to avoid it.

I'm sure there was an encoder switch that helped, but I've forgotten what it was.

Cheers,
David.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #43 – 2013-12-05 16:47:14

I haven't used the command line encoder directly since introduction of SV8.

Quote

Musepack SV8 has been finalized and the first stable release is out. The new stream version offers many improvements over SV7, to users and application developers alike.

Changes:

- Container-independent format. An SV8 MPC is a container file for a Musepack stream. Raw stream encoding is possible.
- Packetized stream allows muxing into audio and video containers (e.g. MKA, MKV, NUT)
- Sample-accurate, fast seeking independent of file length
- Sample-accurate cutting
- Chapters
- No internal clipping. --noxlevel flag removed, not needed anymore

Maybe they fixed it (or maybe not, based on the feedback in this thread).

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #44 – 2013-12-05 20:34:48

Quote from: 2Bdecided on 2013-12-05 16:31:31

You can always apply ReplayGain (or just a fixed gain reduction) before encoding to avoid it. ...

A procedure like this sounds like the solution.
I'm just a bit unsure about precision: If I have foobar use a preAmp gain of say -0.5 dB when encoding: will the scaled data given to Musepack be of higher than 16 bit precision?
An alternative is Musepack's --scale option, but I'm not sure about precision either though I guess this isn't a problem here.

If I could be really sure about scaling precision this is the solution.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #45 – 2013-12-05 22:28:10

Oops, I guess I made a major mistake with my judgement about Musepack's behavior of clipped material.
I just tried to repeat my ABX test with replaygain switched on. Everything was fine now.
So with my first test I must have had replaygain switched off (which is my usual way of ABXing problem samples but which is not appropriate for samples with very high peak values).

So I think it all comes down to do use replaygain while playback.

Sorry for the confusion.

@LedHed8: Did you use Replaygain while playing back your tracks?

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #46 – 2013-12-05 22:30:36

Just about speed;

Code: [Select]

encoding;

 /usr/bin/time -f'%E' mpcenc test.wav 
MPC Encoder 1.30.1 --stable-- © 1999-2009 Buschmann/Klemm/Piecha/MDT
Built Jun 21 2012 07:42:35
     
 encoding file 'test.wav'
       to file 'test.mpc'

 SV 8, Profile 'Standard'

    %|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0  189.2 kbps 14.34x     4:04.1    4:04.1     0:17.0    0:17.0           
0:17.05
---------

/usr/bin/time -f'%E' oggenc -q 5 test.wav 
Skipping chunk of type "LIST", length 104
Opening with wav module: WAV file reader
Encoding "test.wav" to 
         "test.ogg" 
at quality 5,00
	[ 99,8%] [ 0m00s remaining] / 

Done encoding file "test.ogg"

	File length:  4m 04,0s
	Elapsed time: 0m 11,3s
	Rate:         21,5545
	Average bitrate: 159,2 kb/s

0:11.33
---------

decoding;

/usr/bin/time -f'%E' mpcdec test.mpc testmpc.wav
mpcdec - Musepack (MPC) decoder v1.0.0 © 2006-2009 MDT
Built Jun 21 2012 07:42:38
10768943 samples decoded in 910 ms (268.34x)
0:01.27
---------

/usr/bin/time -f'%E' oggdec test.ogg -o testogg.wav
oggdec from vorbis-tools 1.4.0
Decoding "test.ogg" to "testogg.wav"
	[100.0%]
0:04.33
---------

system;

Debian wheezy, CPU~Single core Intel Pentium 4 CPU (-HT-) clocked at 3191.830 Mhz Kernel~3.2.0-4-amd64 x86_64

This is just a single song test,
oggenc > mpcenc
oggdec < mpcdec
(on ancient p4)

edit: And similar for full album;

Code: [Select]

encoding;

/usr/bin/time -f'%E' mpcenc joined.wav 
MPC Encoder 1.30.1 --stable-- © 1999-2009 Buschmann/Klemm/Piecha/MDT
Built Jun 21 2012 07:42:35
     
 encoding file 'joined.wav'
       to file 'joined.mpc'

 SV 8, Profile 'Standard'

    %|avg.bitrate| speed|play time (proc/tot)| CPU time (proc/tot)| ETA
100.0  157.4 kbps 14.58x    36:28.5   36:28.5     2:30.0    2:30.0           
2:30.82
---------

/usr/bin/time -f'%E' oggenc -q 5 joined.wav 
Opening with wav module: WAV file reader
Encoding "joined.wav" to 
         "joined.ogg" 
at quality 5,00
	[100,0%] [ 0m00s remaining] - 

Done encoding file "joined.ogg"

	File length:  36m 28,0s
	Elapsed time: 1m 45,8s
	Rate:         20,6902
	Average bitrate: 134,7 kb/s

1:45.84
---------

decoding;

/usr/bin/time -f'%E' mpcdec joined.mpc joinedmpc.wav
mpcdec - Musepack (MPC) decoder v1.0.0 © 2006-2009 MDT
Built Jun 21 2012 07:42:38
96515496 samples decoded in 8450 ms (259.00x)
0:12.54
---------

/usr/bin/time -f'%E' oggdec joined.ogg -o joinedogg.wav
oggdec from vorbis-tools 1.4.0
Decoding "joined.ogg" to "joinedogg.wav"
	[ 99.5%]
0:27.48
---------

ls -lha joine*
  42M dec  5 23:56 joined.mpc
 369M dec  5 23:59 joinedmpc.wav
  36M dec  5 23:58 joined.ogg
 369M dec  5 23:59 joinedogg.wav
 369M dec  5 23:51 joined.wav

Conclusion; On ancient P4 with this specific OS (All bins are from repos), mpcdec is more than 2x faster that oggdec.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #47 – 2013-12-06 01:17:55

Quote from: halb27 on 2013-12-05 22:28:10

@LedHed8: Did you use Replaygain while playing back your tracks?

I thought I had. However, after getting home from work, I checked my wife's zip clip, and it wasn't enabled. I'm embarrassed that I hadn't noticed this. I'm guessing that it wasn't enabled during our road trip either. I don't think that my wife knows how to turn it on or off. Our other 3 Rockbox'd players all have Replaygain enabled when shuffling. Fortunately, I saved all of the mpc files, so I'll try them again. Sorry to have added to the confusion.

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #48 – 2013-12-06 11:14:12

Offtopic about processor:

Quote from: smok3 on 2013-12-05 22:30:36

Debian wheezy, CPU~Single core Intel Pentium 4 CPU (-HT-) clocked at 3191.830 Mhz Kernel~3.2.0-4-amd64 x86_64
Conclusion; On ancient P4 with this specific OS (All bins are from repos), mpcdec is more than 2x faster that oggdec.

Code: [Select]

Prescott (90 nm)
All models support: MMX, SSE, SSE2, SSE3, Hyper-Threading
Intel 64: supported by F-series, 5x1, 517, 524
XD bit (an NX bit implementation): supported by 5x0J, 5x1, 517, 524

Pentium 4 HT 3.2F     SL7LA     3.20 GHz     1024 KB     800 MT/s     16×     1.25/1.4 V     103 W     LGA 775     August 2004
Pentium 4 HT 541     SL9C6, SL8PR, SL8J2     3.20 GHz     1024 KB     800 MT/s     16×     1.25/1.4 V     84 W     LGA 775     June 12, 2005

Prescott 2M (90 nm)
All models support: MMX, SSE, SSE2, SSE3, Hyper-Threading, Intel 64, XD bit (an NX bit implementation)

Pentium 4 HT 640     SL7Z8 (N0)     3.2 GHz     2 MB     800 MT/s     16×     1.2–1.4 V     84 W     LGA 775     February 20, 2005

Mm... Ok, in technology, 8 to 10 years might be ancient, but your processor is not precisely the usual "P4" processor. I guess that explains why you still use it (i have a northwood 2.8 that i rarely use nowadays).

In terms of instruction set, your builds are 64bit (due to the OS) and so have more registers available, and probably use SSE2 and SSE3 (if allowed by the code and compiler options). Other than better processor architecture, and lower power comsumption (ok, and the lack of multiple cores, which the encoders tested do not make use of), the processor is still competent. (I'm writing this on a mobile core 2 duo 1.5GHz 2MB L2, 667MHz FSB)

How is the quality of MusePack SV8, vs. newer codecs like AAC, Vorbis?

Reply #49 – 2013-12-07 07:42:35

@[JAZ]; Actually the machine is a server and I like the case (It's really quiet), other than that the idea was to tell that results could be very different on today mobile devices.

cat /proc/cpuinfo

Code: [Select]

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 15
model		: 4
model name	: Intel® Pentium® 4 CPU 3.20GHz
stepping	: 3
microcode	: 0x5
cpu MHz		: 3191.936
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
 constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bogomips	: 6383.87
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 15
model		: 4
model name	: Intel® Pentium® 4 CPU 3.20GHz
stepping	: 3
microcode	: 0x5
cpu MHz		: 3191.936
cache size	: 2048 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 1
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 
clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
 constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bogomips	: 6383.98
clflush size	: 64
cache_alignment	: 128
address sizes	: 36 bits physical, 48 bits virtual
power management:

Notice