2008 ripping/encoding general poll Options

[jcoalson]

so does flac, flac's md5 is a layer of checking on top of that which is useful for archival but not much for playback.

[IgorC]

>tak is fast but doesn't compute md5.

TAK uses a checksum for each frame.

So, both FLAC (with MD5) and TAK (frame checksum) are error robust. Correct me if it's not true.
Then FLAC should have MD5 enabled for comparison.

[Synthetic Soul]

EDIT: From the information on his site, Synthetic Soul used TAK 1.0.2b and flac 1.2.1. I recall him doing additional testing since, but am currently searching for more specifics.

I did finish tests on 1.0.3b1 in late December, but what with Christmas, and then me being away for over a week, I totally forgot about it. I'll try to get the 1.0.3b1 data up soon.

[greynol]

So, both FLAC (with MD5) and TAK (frame checksum) are error robust. Correct me if it's not true.
Then FLAC should have MD5 enabled for comparison.

Based on what Josh is saying, flac does not need to compute an md5 checksum to be on par with TAK.

[TBeck]

EDIT: From the information on his site, Synthetic Soul used TAK 1.0.2b and flac 1.2.1. I recall him doing additional testing since, but am currently searching for more specifics.

I did finish tests on 1.0.3b1 in late December, but what with Christmas, and then me being away for over a week, I totally forgot about it. I'll try to get the 1.0.3b1 data up soon.

Thank you so much!

It's great for me to have such a trustable source for TAK evaluations!

So, both FLAC (with MD5) and TAK (frame checksum) are error robust. Correct me if it's not true.
Then FLAC should have MD5 enabled for comparison.

Based on what Josh is saying, flac does not need to compute an md5 checksum to be on par with TAK.

Since we are currently a bit nit-picking: TAK's frame checksum is 24 bit, FLAC's 16 bit... But this shouldn't affect the speed, but only the error detection strength.

This post has been edited by TBeck: Jan 15 2008, 01:01

[Synthetic Soul]

I call shenanigans here, if you're gonna compare speeds don't be comparing FLACs slowest high compression settings with TAKs fastest low compression settings, et al.

Either TAK -p5m vs. FLAC -8 or TAK -p0 vs. FLAC -0 would be a fair speed test. Don't know what the settings should be for the other two encoders off the top of my head... been too long since I last used either.

It's funny what people will call 'fair'. As greynol pointed out, we cannot compare like for like when it comes to compression, as FLAC and TAKs compression range, for my data, do not intersect. In order for FLAC to compete, with comparitive compression, we must use its slowest settings. You need a constant in order to compare the other aspects - i.e.: compression must be constant to properly compare encoding and decoding speed, or encoding speed must be constant to properly compare compression.

Out of interest:

TAK -p5m vs. FLAC -8 (vs. WavPack -hhx3)

CODE

              %       E       D
TAK     63.532%     10x     93x
FLAC    65.476%     19x    120x
WV      64.378%      4x     58x

TAK -p0 vs. FLAC -0 (vs. WavPack -f)

CODE

              %       E       D
TAK     65.281%    110x    129x
FLAC    70.674%    134x    141x
WV      66.741%     73x    103x

Note that TAK ranges 63.532-65.281% and FLAC ranges 65.476-70.674%.

Perhaps we should consider default values:

CODE

                 %       E       D
FLAC       65.721%     53x    124x
MA         63.793%     41x     38x
TAK        64.093%     62x    113x
WavPack    65.582%     64x     88x

Now once you use flac -0, things do indeed change, but it seems most people around here don't use -0...
http://www.hydrogenaudio.org/forums/index....showtopic=58731

The vast majority of people taking that poll indicate that they use -8. Certainly it may be fast enough, but it isn't anywhere near "average" or "above average". This is the only point I'm trying to make.

I find it very interesting that the majority (59%) of FLAC users are using -8, and 97% of users who voted use -5 or over. It shows that these "negligable" values are... well, not so negligable.

if you're talking about why people choose a codec, I doubt that matters. all encoders are fast enough. encoding is done once. flac is fastest where it matters most (decoding). being below average in compression is not a big deal when all codecs are within a few % of each other.

We must also remember that really fast decoding speeds are irrelevant, when restricted by I/O. I changed my reported values from global time to processing time as I was seeing major drop-offs in speed due to hardware restraints. Anything over 60x was being noticeably affected, and nothing could get much past 80x.

All said and done, I agree with the majority that there is little between the major codecs. It should come down to feature set, compatibility, error tolerance, etc. TAK is still in its early stages, yet it is already proving to be a strong contender. WavPack is a superb, easy to use, all-round codec with a fantastic feature set. FLAC is robust, fast and proven, and it will take some change for it to be toppled from its current position.

[IgorC]

We must also remember that really fast decoding speeds are irrelevant, when restricted by I/O. I changed my reported values from global time to processing time as I was seeing major drop-offs in speed due to hardware restraints. Anything over 60x was being noticeably affected, and nothing could get much past 80x.

Excelent. It will be more usefull to see the numbres under real conditions.

[TBeck]

EDIT: From the information on his site, Synthetic Soul used TAK 1.0.2b and flac 1.2.1. I recall him doing additional testing since, but am currently searching for more specifics.

I did finish tests on 1.0.3b1 in late December, but what with Christmas, and then me being away for over a week, I totally forgot about it. I'll try to get the 1.0.3b1 data up soon.

Thank you so much!

It's great for me to have such a trustable source for TAK evaluations!

Thanks for the update!

Some comments in the TAK 1.0.3 thread.

Thomas

[Engywuck]

another question...
when I look at the graph for lossy codecs I see a gigantic surge in 2003 for Musepac, with continuous decline for it afterwards.

Why did it have such great figures then? New codec version released shortly before? Some other super-duper-hype?
And what's the final reason for it's constant decline afterwards? LAME getting so much better?

BTW: I voted for FLAC/MP3/by file

[Brent]

Lossy is a difficult problem, because as a whole it's depricated to me in favor of lossless (FLAC). But if I would choose a lossy format, it would be whatever AoTuV's latest Vorbis build would be, because it's free (OS) and good. Yet, if lossy is required, I nearly always choose MP3, because it's a) good enough (V5 or something) b) play's _everywhere_ and it on the virge of being patent and license free too.

[shadowking]

another question...
when I look at the graph for lossy codecs I see a gigantic surge in 2003 for Musepac, with continuous decline for it afterwards.

Why did it have such great figures then? New codec version released shortly before? Some other super-duper-hype?
And what's the final reason for it's constant decline afterwards? LAME getting so much better?

BTW: I voted for FLAC/MP3/by file

Musepack started as a more efficient vbr solution at the time to mp3. AAC and vorbis were still maturing. Lack of development for some time, missing seeking, compatibility worries drove more and more people away. This is in conjunction to maturation of other codecs and lossless encoding. In the last 2 years there are more hardware playback options available, good seeking and development has picked up again. its really not much less supported than aac if you forget the ipod.

Biggest problem ?

- Needs a return to its roots. Currently MPC serves mostly as a transcoding hack from --insane --braindead. Instead, We should rockbox a device, buy a Cowon, stop transcoding and return to efficient size and great quality for --standard and --extreme.

- There has been no psymodel adjustments for years. Issues are minor but Klemm or someone alike is ultimately needed.

[sh1leshk4]

For lossless now I choose TAK over WavPack, due to speed and compression reasons.
I don't care about compatibility since it's only for archival and local playback (on my PC); for portables I use lossy.
Still waits until it's ready to be open-sourced and then ported over to *nix systems, though.

Subjectively speaking (which means for my ears only), for quality reasons now I choose AAC over MP3 for lossy.
With AAC I can accept ~128kbps while with MP3 a -V2 setting is a minimum requirement.
Back then I'm with Vorbis (aoTuV was the only reason I stick with it) but in general I've moved over from that one.

[jcoalson]

EDIT: From the information on his site, Synthetic Soul used TAK 1.0.2b and flac 1.2.1. I recall him doing additional testing since, but am currently searching for more specifics.

I did finish tests on 1.0.3b1 in late December, but what with Christmas, and then me being away for over a week, I totally forgot about it. I'll try to get the 1.0.3b1 data up soon.

updated my comparison too, to tak 1.0.3b and ape 4.01. tak turbo seems about 5% faster than version 1.0.1 on this corpus
http://flac.sourceforge.net/comparison_all_cpudectime.html

[TBeck]

...
updated my comparison too, to tak 1.0.3b and ape 4.01. tak turbo seems about 5% faster than version 1.0.1 on this corpus
http://flac.sourceforge.net/comparison_all_cpudectime.html

Thank you! That's very interesting for me, because your file sets differs very much from Synthetic Soul's.

For the decoding speed: The increase from V1.0.1 to 1.0.3 is about 15 percent on a P3. Since TAK isn't using any P3 specific instructions, i assume the slower L2-Cache of your P2 is the reason for the smaller increase in your test.

Could you please also include TAK's strongest mode -p5/-p5m (aka "Insane")? This was -p4 in TAK 1.0.1, but TAK 1.0.2 inserted the new turbo preset...

Thomas

[jcoalson]

added graphs: http://flac.sourceforge.net/comparison.html (scroll down)
will add tak insane as soon as the run finishes.

[TBeck]

will add tak insane as soon as the run finishes.

Thanks.

[IgorC]

added graphs: http://flac.sourceforge.net/comparison.html (scroll down)
will add tak insane as soon as the run finishes.

Is something wrong with numbers of highest ratios? http://flac.sourceforge.net/comparison_all_ratio.html

Tak 1.0.3b (insane max) 383.78 MB 50.60%
Monkey's Audio 4.01 (insane) 381.79 MB 50.65%

This post has been edited by IgorC: Jan 24 2008, 16:21

[jcoalson]

no, average ratio is used instead of overall ratio to keep longer tracks from having too much influence. see also http://flac.sourceforge.net/comparison.html

the inversion is due to ape insane doing much better on the long indian classical track.
http://flac.sourceforge.net/comparison__l_..._sivapriya.html

[NetRanger]

Lossy: MP3 -V0

Lossless: FLAC Q8

One file/track

[IgorC]

no, average ratio is used instead of overall ratio to keep longer tracks from having too much influence. see also http://flac.sourceforge.net/comparison.html

the inversion is due to ape insane doing much better on the long indian classical track.
http://flac.sourceforge.net/comparison__l_..._sivapriya.html

Thanks. Got it.

[VCSkier]

Back when I was active on these forums, I was a committed Wavpack user, and I used LAME to encode my local mp3 files. Since I because a linux user almost two years ago, I've switched to FLAC and OGG. CD's that I want to archive for potential reproduction, I use K3B to rip to a FLAC image with a cuesheet. For playback, I rip my cd's to ogg files (one per track). I really enjoy this method, as all native linux tools very comfortable and naturally handle the FLAC and Vorbis formats, and integration is excellent.

[A_Man_Eating_Duc...]

@VCSkier

Did you ever find a linux player that fully supported CUE+FLAC's?

[VCSkier]

@VCSkier

Did you ever find a linux player that fully supported CUE+FLAC's?

Nope. But K3B rips and burns them. Maybe someday, but in the meantime, I have no problem just using my vorbis track-files for playback.

[Daniel Beaver]

Oh, I suppose I will throw in my two cents.

My music is 58.8% mp3 and 41.2% aac. ABX tests on my part revealed that a -V5 (128k) mp3 sounds transparent to me when listening through my sennheiser 497 headphones connected to my laptop (the best audio equipment that I own). Therefore, Mp3 is "good enough" for my uses. Given that, it is somewhat irrelevant to me what lossy format I use, as long as my player supports it.

I keep a flac backup of all my CD's on an external hard drive. I don't put much thought into lossless formats, since for me there are no practical differences between them (foobar plays all of them, and the compression ratios are similar).

The huge drop in Musepack usage is interesting. I would guess that has to do with the lack of hardware support, and also because rockbox-supported players are getting old.

[S-12]

It's very interesting to see the trends over the past five years of these polls. The first time I ever voted in one here, MPC and Vorbis numbers were essentially reversed from where they are so far in this poll - MPC was holding steady in second place behind MP3, while Vorbis was gradually inching up from about 1/3 the number of MPC's votes. And look at them today: Vorbis has gained a dramatically increased user base, and FLAC seems to have steadily (though more gradually) increased in popularity from 5 years ago as well.

I'd attribute the success of Ogg Vorbis to (a) continued hardware support year-to-year, and (b) steady, continual development improving the quality of the format, helped well along by its open source status. Nowadays I use Lancer -q5 exclusively for my lossy encoding. Even problem samples like Fatboy are transparent to me in casual listening now with the latest encoder version - a far cry from prior releases. Or maybe it's just because my ears, being now middle-aged, can no longer discern variances as well as they once could. But regardless, I still want to thank everyone who has continued to put their time and effort into Vorbis development since its inception.

I voted for Vorbis (all of my hardware devices are compatible with it), FLAC (likewise) and one file per CD track. There's an exception to the latter, though, for tracks which in my opinion "always go together", such as INXS ~ Need You Tonight/Mediate, The Cars ~ Shoo Be Doo/Candy-O, and some Pink Floyd tracks including ABitWp1/HDooL/ABitWp2 and Empty Spaces/Young Lust.

Soon after I began here in 2002 I encoded my collection into FLAC (v1.0.8, I believe) for lossless reference and Vorbis (first Xiph v1.0, then GT3b1) for portability. I've re-encoded a few times since, mostly because of an interest in various psychoacoustic encoding formats during the time I was participating heavily in RA's listening tests. But, for the most part, I haven't strayed from that initial, successful formula. It's served my needs very well in the years I've used it so far.