Hi It's been sometime since I used this codec I have a several old albums encoded with musepack. I use an Ipod video 80gb with rockbox and have since started using autov vorbis and wondered how sv8 compares with todays modern codecs such as apple/nero aac or vorbis.
Depends at the bitrate your targeting . Below 128k no question AAC / vorbis are superior. The real strength of MPC is the default profile @ 160..180k yields very high quality. I would trust it over modern 256~320k encodings of mp3 / acc . Vorbis aotuv could be same quality maybe even better but no one knows for sure. I still think MPC has an advantage in some areas like pre-echo. Battery life should be better with MPC vs vorbis.
I also like that MPC has all the tools and encoders developed in one place.
shadowking, you would put MPC at ~160-180 kbps over ~256-320 kbps AAC? Are you also saying that Ogg Vorbis at ~160-180 is "better" than AAC at ~256-320?
No , I think vorbis 'better' or on-par may be at higher bitrates like Q7 (224k) . Q6 at the very least (190k).. I still think at moderate-high bitrate (160..210k) mpc @ Q5 / 6 has the edge over AAC 256 and mp3 320 and even vorbis. For an 'extreme' setting i'd take mpc Q6 (205k) anyday over the others @ 256-320. Even mpc 'insane' profile yields lower bitrate (240k) while allowing full bandwidth encoding which the others don't. Even at medium bitrates say 130..160k mpc (--radio / Q4 ~4.5) will perform very well and is well suited for portable use. Its just that it will pretty much suck at 100k or lower and vorbis / aac are better 'overall' performers in that sense.
Another observation is that mpc is a really fast encoder without any 3rd party versions. Faster on my pc than lame mp3, aac, vorbis and close to aotuv lancer.
Battery life should be better with MPC vs vorbis.
I fully agree.
In my testing with MPC SV8 on android device realized a reduction of approximately 2~3% in CPU usage and, as a result, longer battery life.
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.
In my tests MPC is very competetive in quality at Q5 and encoding and decoding speed is amazingly fast. Although i've just used it seldomly because other formats are more common if i have to share them with somebody else.
shadowking, you talk about MPC like it's the best lossy codec ever created. I understand it may be good but I wouldn't even compare it to AAC, not even once.
Let me understand one thing, if it's so good why did they stop adding it into listening test since 2004? It's obsolete.
Let me understand one thing, if it's so good why did they stop adding it into listening test since 2004?
Because it was found to be transparent over the range of bitrates it was made for. No sense doing listening tests if they can't tell you anything new.
So it looks like the codec is on par with today's modern codecs because of everything done to it and is finalized. Thats the reason I could not find an updated listening test to compare it with.
Terms of Service 8 called. Apparently no one here knows it so they never picked up... >_>
Well I encoded 2 albums different genres and Indeed their is better battery life with rockbox compared with the same albums encoded in vorbis. I find musepack indistinguishable from the flac files i encoded from. Thanks for the support everyone who answered this thread but I have the feeling some of us might have got off topic and violated Tos 8 of the forums.
Also yes, MPC's decoding speed is very fast but AAC and Ogg Vorbis are almost double the speed. Am I doing something wrong in my test?
http://dropcanvas.com/vq4w7?expand (http://dropcanvas.com/vq4w7?expand)
edit:
Adding more lossless in a bit.
edit2:
Done.
@ eahm Maybe so on pc but I was referring to rockbox firmware for the Ipod video 5.5G it does have it's processing limitations. Interesting benchmark testing though.
@ eahm Maybe so on pc but I was referring to rockbox firmware for the Ipod video 5.5G it does have it's processing limitations. Interesting benchmark testing though.
Thanks. OT: To me the most interesting thing is why WAV is slower than AIFF. I need to find a book/website where I can study the decoding process, I like it more than anything else in audio.
OT: To me the most interesting thing is why WAV is slower than AIFF. I need to find a book/website where I can study the decoding process, I like it more than anything else in audio.
Little vs big endian?
IIRC, the developer, Bauschman (?), just didn't have time nor the motivation to continue with the Musepack project, and his computer broke down at the same time. People here were so frustrated (and desperate), they even offered him money for a new computer so he could continue with his work. But in the end, he abandoned the project. It was a while ago, but that's what I think happened.
IMO Buschmann & Klemm where way ahead of the game and their time - We are talking circa 2000 where 128k and swooshing were commonplace. MP3 was only stable more or less at 192 CBR. VBR was hit and miss + slow, AAC was still immature, Vorbis plagued by a HF noise. MPC quality was already nearly finalized at that time. Klemm made the encoder very fast by 2002. Lame -APS was a fat lumbering elephant compared to mpc Q5.
The trouble was the format was ahead of its time. At least today with phones / tablets you can load a player that will handle mpc and other non common formats. The other problems was the two developers never had much time to finalize the format in terms of specs etc.. This is where vorbis got it right sort of but similar loss of interest happened there too till this day. Vorbis had big quality issues until aotuv. Several people tried to fix it but only aotuv developer could do it. If he didn't come along vorbis would have remained same quality till today. Anyway around 2004-5 MDT did a good job with the help of klemm and buschel - but in the gap around 2003-2005 a lot of damage was done. Without a developer / maintainer people got scared and started leaving.
People here were so frustrated (and desperate), they even offered him money for a new computer so he could continue with his work. But in the end, he abandoned the project.
The computer fundraising was not to coerce Klemm to continue, it was pitched more as a thank-you for his work to that point. Some were hopeful that it might catalyze him to contribute more. However, he open-sourced, and SV8 happened, and Musepack is as good as it's ever been.
Whenever I can say "Fuck compatibility, I want transparency at low bitrates", I end up going with Musepack. The fact that it's light on decoding resources is a lovely plus.
Whenever I can say "Fuck compatibility, I want transparency at low bitrates", I end up going with Musepack. The fact that it's light on decoding resources is a lovely plus.
"Low bitrates"? Are we still talking about ~180 kbps? I thought low are ~64/96 (Opus, AAC)?
"Transparency at low bitrates" means 140-180ish to me. Below that point there isn't transparency (except Opus and maybe HE-AAC, but the latter has never ABXed well for me). Medium bitrate would be LAME V0. High bitrate is lossless.
I'm old. So sue me.
I think to summarise:
Listening tests are too hard at near-transparent bitrates, so in recent years listening test bitrates have come down (128, 96, 64, 48 etc). This has led to Musepack not featuring as it's very uncompetitive below 128.
Musepack is great and very well tuned for transparent audio (Q5 or above) and still remarkably good at Q4 (128kbps or so).
Below Q4 bitrate starvation causes the quality to degrade quickly like a lot of old technology codecs like MP2, MP3 which don't have special tricks to hide degradation or to encode stereo adequately with much lower bitrate.
Ogg Vorbis has some tricks to roughly maintain the coarse critical band energy, but this was discovered late in its development so isn't implemented as efficiently as it might be, but it's pretty good down to about 80 kbps in AoTuV. Opus/CELT had this as a fundamental part of its design, implemented efficiently. Both have smart ways to encode stereo efficiently at lower bitrates.
AAC-LC has some efficiencies, making it good down to about 96kbps. Below that, the flaws in LC get rapidly worse, so HE-AAC is better by the time we reach 64kbps and we put up with Spectral Band Replication being an inexact representation of the high end. Below about 48 kbps, Parametric Stereo is also introduced to enable even lower bitrates with a good impression of bright full range sound, but certainly frequent flaws at 24 kbps.
It seems that AAC-LC and Opus are contenders for providing transparency at about 128kbps average (subject perhaps to further careful tuning).
IMO Buschmann & Klemm where way ahead of the game and their time - We are talking circa 2000 where 128k and swooshing were commonplace. MP3 was only stable more or less at 192 CBR. VBR was hit and miss + slow, AAC was still immature, Vorbis plagued by a HF noise. MPC quality was already nearly finalized at that time. Klemm made the encoder very fast by 2002. Lame -APS was a fat lumbering elephant compared to mpc Q5.
Buschel is still active working on Rockbox from time to time. He fixed up our MPC and AAC decoders quite a lot, which is part of why MPC is now so efficient on ARM devices.
@ eahm Maybe so on pc but I was referring to rockbox firmware for the Ipod video 5.5G it does have it's processing limitations. Interesting benchmark testing though.
Thanks. OT: To me the most interesting thing is why WAV is slower than AIFF. I need to find a book/website where I can study the decoding process, I like it more than anything else in audio.
Where are you looking?
Out of curiosity I tried my worst problem samples harp40_1, herding_calls, eig, lead-voice, trumpet_myPrince with Musepack SV8 using standard quality (5).
I'm really impressed, quality is great. I did only a short ABX test and didn't succeed with any of these samples (though I do believe I can ABX eig when applying a lot more effort). For practical listening I'm totally happy with these results.
More interesting to me: my Nokia C7 smartphone was broken recently, and I replaced it with a SONY Xperia L android smartphone for which I use Poweramp for listening to music. I just realized that Poweramp plays mpc files (as do other android players). My home stereo player is a Rockbox armed Clip+, so no problems here too.
So I could use Musepack, so far. I don't care about codec development to have discontinued as the codec seems to be great. What I care about is playback support on modern devices, and this seems to look good.
Sharing music has come down for me to share music with my wife. She can't use Musepack so this is still a problem. A minor one though as she has her collection, and additions don't happen frequently.
I'm used to change loudness by modifying the mp3 scale factors according to RG value using foobar, with a higher amount of manual RG modification, and I have written a tool to take these RG values to renewed encodings. I can't migrate this process to Musepack, but as PowerAmp and Rockbox can make use of RG values for playback, I can find a corresponding solution.
I'll think about it.
Out of curiosity I tried my worst problem samples harp40_1, herding_calls, eig, lead-voice, trumpet_myPrince with Musepack SV8 using standard quality (5).
I'm really impressed, quality is great. I did only a short ABX test and didn't succeed with any of these samples (though I do believe I can ABX eig when applying a lot more effort). For practical listening I'm totally happy with these results.
Me too. I've been impressed so far using standard quality. I've resisted trying Musepack because it seemed "fringe and obsolete". It might be fringe, but there does not seem to be anything obsolete about the sound quality. From a quick couple of encodes and listens, I must encode more music and try it for a while. Even my wife, who could generally care less about my sound obsession, was genuinely impressed with the Musepack sound.
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).
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)?
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.
[..] 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.
[..] 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:
==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?
Here (http://dl.getdropbox.com/u/2681777/test/Bolero_extract.flac) it is.
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.
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.
All my mobile library is in Musepack format.
Initially I worked with quality 'Extreme' and 'Braindead' (--quality 7 and 8), 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
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.
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.
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.
clipped material tends to sound worse than the original
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.
MPC runs into "internal clipping" every now and then. You could see it if you were using the command line encoder manually.
clipped material tends to sound worse than the original
... 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.
Sorry, posting error on my side.
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.
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.
I haven't used the command line encoder directly since introduction of SV8.
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).
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.
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?
Just about speed;
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;
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.
@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.
Offtopic about processor:
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.
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)
@[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
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:
I've been a bit lazy with HA recently, but I think I should report this event which happened a while ago:
After being happy with my Musepack Q7 collection for quite a long period I ran upon Joni Mitchell's 'Cool Water' in a normal listening situation. The music sounded subtly 'wrong'. So I did an ABX test and succeeded 5/5 without much problem. The problematic original part is here (http://dl.getdropbox.com/u/2681777/Problems/CoolWater.flac).
This disappointed me pretty much to the point that I came back to mp3. I don't care about bitrate, and with mp3 @~300 kbps I have a lot of practical experience and I feel pretty safe with respect to my personal quality demands.
This disappointed me pretty much to the point that I came back to mp3. I don't care about bitrate, and with mp3 @~300 kbps I have a lot of practical experience and I feel pretty safe with respect to my personal quality demands.
Just my two cents but on a personal level, I gave in to the fact that, whilst chasing the perfect lossy codec, my now 15-year old well-trained ears
are actually to blame for most of the flaws I am still able to unexpectedly detect to this day whilst enjoying my beloved tunes, more than any modern lossy codec's own obscure, then-unheard-of flaw.
But that ended somehow as soon as I started to rely mostly on hybrid Wavpack and its whole new approach to portable encoding for my "lossy needs" instead.
Yes, Wavpack hybrid and lossyFLAC are very good solutions, but being lossy too they take >400 kbps on average for peace of mind. If you can allow for that (I'm a bit on the edge here ATM) the best solution IMO.
Yes, Wavpack hybrid and lossyFLAC are very good solutions, but being lossy too they take >400 kbps on average for peace of mind.
I can't vouch much for lossyFLAC for simply not using it. And though I don't want this thread to drift off-topic, I must say on the other hand, you'd be surprised with the much lower bitrates you can get away with (~280kbps) for Wavpack's hybrid mode, as long as you acknowledged some simple, quite strong arguments for that:
a) the inherent real-world background noise where you'll be doing most of your portable listening is pretty similar to the white noise you may detect on some circumstances - which is obviously not the case with psychoacoustics-based encoders' artifacts;
b) the fact you can always have that ever-present reassurance you'll have the lossless correction file for any occasion that may arise when you'll have to re-encode anything.
This disappointed me pretty much to the point that I came back to mp3. I don't care about bitrate, and with mp3 @~300 kbps I have a lot of practical experience and I feel pretty safe with respect to my personal quality demands.
There is no reason not to choose the best codec (or codec setting) for each track, or at least each album, individually. Every codec has its own problematic samples.
This disappointed me pretty much to the point that I came back to mp3. I don't care about bitrate, and with mp3 @~300 kbps I have a lot of practical experience and I feel pretty safe with respect to my personal quality demands.
There is no reason not to choose the best codec (or codec setting) for each track, or at least each album, individually.
Sanity, and the finite lifespan of each human, seem like two fairly good reasons
not to do this!
Cheers,
David.