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: New lossless codec comparison (Jan '13) (Read 55644 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New lossless codec comparison (Jan '13)

Reply #25
I transcoded my FLACs from -8 to -5 and there was *very* little size increase.  This will likely help out my battery life at a tiny size cost. Thanks for the input guys.


saratoga can probably speak as to the specifics of that player, but on Porta Player devices the difference in decode speed would equal ZERO, not a little, but zero power savings as the CPU doesn't clock lower than 30Mhz.  Whereas the size difference would equal (probably insignificant but) real power consumption differences due to increased storage access.  Flash obviously cuts the power consumption of storage access down vs spinning rust, but the number is real.
Creature of habit.

New lossless codec comparison (Jan '13)

Reply #26
I've got a bit of a noob question.  I just RockBox'd a Sansa Clip+ and I'm trying to find the best lossless encoding that balances file size and battery life.  Right now I'm using FLAC-8.  I'm assuming that on the decoding graph a higher value on the X-axis equates to better decompression ie. better battery life?
I've ran a test on my clip+ with an album encoded with flac -11 (CUETools's flaCL) and the same with wavpack -hhx and the difference was only about 10 minutes in runtime, so I'd say lossless encoding options don't affect battery life that much anymore.

New lossless codec comparison (Jan '13)

Reply #27
I should have replied a lot earlier, because your publication immediately made me very happy.

Eventually a lossless codec comparison i feel i can trust!

In the past it was Synthetic Soul's comparison, although his sample selection was not sufficiently diverse (at least for my purposes).

When i am thinking about tuning opportunities for my codec, i often look at your results.

I think, you aren't  getting as much feedback as you deserved here at hydrogen, but hey, your comparison has been published on the FLAC web site, and i am sure, the guys over there too know what constitutes a meaningful lossless codec comparison.

I must admit, i am selfish. I wanted to thank you but i also want to encourage you to continue your valuable work. Because it's so important to me, to have an independent instance, which verifies the outcome of my work.

Again

thank you! 

  Thomas

New lossless codec comparison (Jan '13)

Reply #28
I should have replied a lot earlier, because your publication immediately made me very happy.

Eventually a lossless codec comparison i feel i can trust!

Well, that's nice to hear!

Quote
In the past it was Synthetic Soul's comparison, although his sample selection was not sufficiently diverse (at least for my purposes).

As the issue is brought up now, I would like to ask for a little help once again. I've been looking for more music to make the sample selection even more diverse, and I now have this list of 43 albums, where the previous comparison was with 29 albums.

  • 30 Seconds to Mars - This Is War (rock)
  • Abba - Gold: Greatest Hits (1992) (pop)
  • Albert King - Years Gone By (blues)
  • Alicia Keys - The Diary of Alicia Keys (R&B, soul)
  • Alison Krauss Union Station - New Favorite (country, bluegrass)
  • Armik - Rain Dance (flamenco/jazz)
  • Café del Mar - Volumen nueve (chill-out)
  • Coldplay - Parachutes (pop)
  • Confido Domino Minsk - Sacred choral music from White Russia (choral, religious)
  • Daft Punk - Alive 2007 (electronic)
  • Dan Brown - Angels and Demons (audiobook)
  • Enya - Amarantine (new age)
  • Fanfare Ciocarlia - Baro Biao: World Wide Wedding (world music, brass)
  • Gilberto Santa Rosa - Esencia (salsa)
  • Giuseppe Verdi - Messa da Requiem (Berliner Philharmoniker feat. conductor Claudio Abbado) (orchestral, romantic)
  • Howard Shore - The Hobbit: An Unexpected Journey (orchestral, OST)
  • Iron Maiden - Brave New World (metal)
  • James Brown - Love, Power, Peace (Live at the Olympia, Paris, 1971) (funk)
  • John Coltrane - Live at the half note, vol. 1 (jazz)
  • Joss Stone - Mind, Body & Soul (soul)
  • J.S. Bach - Magnificat (orchestral, baroque)
  • Koninklijke Militaire Kapel - [no name] (military brass)
  • Kraftwerk - Autobahn (electronic)
  • Lana del Rey - Born to Die (pop)
  • Lil Wayne - Tha Carter III (hip hop)
  • Martin O'Donnell & Michael Salvatori - Halo: Reach (ambient-ish, OST)
  • Metallica - Death Magnetic (metal)
  • Michael Bublé - meets madison square garden (pop, jazz)
  • Mike Oldfield - Tubular Bells (2000 remaster) (not classifiable)
  • 'N Sync - Home for Christmas (pop)
  • Nicholas Hooper - Harry Potter and the Order of the Phoenix (soundtrack)
  • Peter Tosh - Equal Rights (2011 legacy edition) (reggae)
  • Rosenberg Trio - Djangologists (jazz)
  • Rush - Grace under Pressure (1997 remaster) (rock)
  • System of a Down - Mezmerize (metal)
  • Szakcsi - Virágom, virágom (world music)
  • Tiësto - In Search of Sunrise 7: Asia (dance)
  • The Lumineers - The Lumineers (folk)
  • Various - Jeff Waynes Musical Version of The War of the Worlds (radio drama-ish, rock, orchestral)
  • Waylon Jennings - Honky Tonk Heroes (country)
  • Various - Latin Village, CD 1: Salsa (salsa)
  • Xzibit - At the Speed of Life (hip hop)
  • Yann Tiersen - Le Fabuleux Destin d'Amélie Poulain (minimalism)


The bold items are new. I think this is a nice list so far, any comments?

Quote
I must admit, i am selfish. I wanted to thank you but i also want to encourage you to continue your valuable work. Because it's so important to me, to have an independent instance, which verifies the outcome of my work.

But the comparison wasn't totally fair yet. I ran your codec in Wine, and while one could argue Wine doesn't add much overhead, it's a little weird I didn't run FLAC trough wine too, for example.

Anyway, the next version of this comparison will have all codecs tested on a Windows computer, as I finally figured out a utility that reported the CPU cycles used by a certain program instead of time elapsed. I rewrote my scripts to fit in a Windows enviroment, technically I'm ready to run it, but I am waiting for WavPack 4.70 final to be released (so I can test new versions of FLAC, TAK, Monkeys Audio and WavPack), so the result will be published somewhere this summer I suppose.

If there are still any remarks on the test setup, please tell me. I can still fix things now

edit: oh, and for the record, I will be testing on per-track basis instead of per-album basis now. Every album will be weighted equally just as the previous comparison, but now I will be able to identify outliers. Maybe something interesting pops up.
Music: sounds arranged such that they construct feelings.

New lossless codec comparison (Jan '13)

Reply #29
...
Anyway, the next version of this comparison will have all codecs tested on a Windows computer, as I finally figured out a utility that reported the CPU cycles used by a certain program instead of time elapsed.
...

What is the name of this utility?

New lossless codec comparison (Jan '13)

Reply #30
What is the name of this utility?

It's timeit.exe, from the Windows Server 2003 Resource Kit Tools. However, it doesn't work with Windows 7 (I run Windows XP) but I found something that indicated powershell might have similar capabilities, but I didn't test. If anyone is going to dive into this, please report any finding, I'm not entirely sure this timeit utility reports are resembling the truth. It says process time, but the results I got back were sometimes weird for no apparent reason.
Music: sounds arranged such that they construct feelings.

New lossless codec comparison (Jan '13)

Reply #31
I've got a bit of a noob question.  I just RockBox'd a Sansa Clip+ and I'm trying to find the best lossless encoding that balances file size and battery life.  Right now I'm using FLAC-8.  I'm assuming that on the decoding graph a higher value on the X-axis equates to better decompression ie. better battery life?
I've ran a test on my clip+ with an album encoded with flac -11 (CUETools's flaCL) and the same with wavpack -hhx and the difference was only about 10 minutes in runtime, so I'd say lossless encoding options don't affect battery life that much anymore.
To update on this, I ran some more tests and the differences are bigger. I found out flac -11 sometimes fails to decode on the clip+ (probably because it's not a subset file), so I switched to flac -8 and battery wise, flac is a clear winner:

Code: [Select]
Flac -8:         16:09:49
Wv -hh -b384x:    11:17:12
mp3 v0:            11:48:20
vorbis q5:        12:17:56
opus 160:        10:17:00


Complete battery_bench logs here

New lossless codec comparison (Jan '13)

Reply #32
It's timeit.exe, from the Windows Server 2003 Resource Kit Tools. However, it doesn't work with Windows 7 (I run Windows XP) but I found something that indicated powershell might have similar capabilities, but I didn't test.


just yesterday i was wondering if there was a tool for benchmarking command line programs and i found this.

I use timer.exe from 7-Benchmark: http://sourceforge.net/projects/sevenmax/files/7-Benchmark/


it works on windows 7. i also tried the powershell command. you can see the results here - i did a quick test of flac and takc on a single album image.

https://dl.dropboxusercontent.com/u/2280132.../june/bench.png

New lossless codec comparison (Jan '13)

Reply #33
I hope this time your Windows computer can run flacCL. Would be nice to see it included.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

New lossless codec comparison (Jan '13)

Reply #34
Thanks ktf.

New lossless codec comparison (Jan '13)

Reply #35
just yesterday i was wondering if there was a tool for benchmarking command line programs and i found this.

Yes, I saw that one too, but the problem is it reports running time, not CPU time used. I just took another look at powershell, it seems to report real time as well, not CPU time.

I hope this time your Windows computer can run flacCL. Would be nice to see it included.

I'm sorry, the test needs several weeks to run, so I can only use an old computer that's not longer used from before the GPGPU era to do this work.

However, I might as well add a section on different FLAC-encoders run on a different computer, but I will have to work that out.
Music: sounds arranged such that they construct feelings.

New lossless codec comparison (Jan '13)

Reply #36
Yes, I saw that one too, but the problem is it reports running time, not CPU time used.

I thought that "Process Time" is CPU time. What is the difference between them?

New lossless codec comparison (Jan '13)

Reply #37
Since common PCs do have more than one running core for several years now, there is a distinction between the time required for a task (elapsed time) and the time required for one working unit to complete it (cpu time).

In Windows, there's a gauge showing the usage from 0 to 100%, but in linux, the "top" utility can show usages of 150%, 200% or more. This is translated as using more than the time that a single working unit is able to provide.

 

New lossless codec comparison (Jan '13)

Reply #38
I'm sorry, the test needs several weeks to run, so I can only use an old computer that's not longer used from before the GPGPU era to do this work.

What CPU does it have and what instructions does it support (SSE, SSE2, etc.)?

New lossless codec comparison (Jan '13)

Reply #39
I thought that "Process Time" is CPU time. What is the difference between them?
You're right. I don't know why I concluded that 7bench is not able to measure CPU-time, because it clearly can. It does give the same results as timeit (and the same pecularities, like having a smallest increment of 0.015s at my system) so I suppose it uses the same kernel hooks.

What CPU does it have and what instructions does it support (SSE, SSE2, etc.)?
If you really want to know, the introduction date of this processor was March 10, 2005, I bought the laptop around the time the first dual-cores hit the mainstream market. Details are below. Wikipedia says: MMX, Enhanced 3DNow!, SSE, SSE2, SSE3, AMD64, PowerNow!, NX Bit
Code: [Select]
processor       : 0
vendor_id      : AuthenticAMD
cpu family      : 15
model          : 36
model name      : AMD Turion™ 64 Mobile Technology ML-34
stepping        : 2
cpu MHz        : 1800.141
cache size      : 1024 KB
fpu            : yes
fpu_exception  : yes
cpuid level    : 1
wp              : yes
flags          : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt
lm 3dnowext 3dnow rep_good pni lahf_lm
bogomips        : 3600.28
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes  : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Music: sounds arranged such that they construct feelings.

New lossless codec comparison (Jan '13)

Reply #40
As the issue is brought up now, I would like to ask for a little help once again. I've been looking for more music to make the sample selection even more diverse, and I now have this list of 43 albums, where the previous comparison was with 29 albums.

Usually more is better. As long as the codec relevant audio properties and there share of all audio files can't be fully determined, i don't know a better way to improve the representativity.

Do you know if your selection contains some hypercompressed files?  Since they are so common know, this seems to be one more important category. I don't really like to ask for it, because i know that TAK performs less well on them...

I don't thinky you would need plenty such files. From my experience the effect of other codec relevant audio properties usually is quite small, if a file is hypercompressed.

But the comparison wasn't totally fair yet. I ran your codec in Wine, and while one could argue Wine doesn't add much overhead, it's a little weird I didn't run FLAC trough wine too, for example.

I wouldn't expect a significant effect. I have examined some comparisons which ran in Wine, and the results were in line with windows comparisons. I really like that you care so much about so many details, but i think it's nearly impossible to create a practicable comparison that everybody regards as fair. One could criticize, that you will be using a quite old cpu, because it lacks some instruction set extensions or because possibly newer compilers will not generate optimal code for it. On the other hand there are also good arguments against the use of a newer cpu. But someone will always complain.

I myself feel comfortable with your cpu choice. While it dosen't support SSSE3, what will make TAK's stronger presets somewhat slower, it's microarchitecture doesn't differ too much from more recent cpus.

Well, i probably would protest, if you were using one of those strange Pentium 4 - cpus...

edit: oh, and for the record, I will be testing on per-track basis instead of per-album basis now. Every album will be weighted equally just as the previous comparison, but now I will be able to identify outliers. Maybe something interesting pops up.

Great!

New lossless codec comparison (Jan '13)

Reply #41
Do you know if your selection contains some hypercompressed files?  Since they are so common know, this seems to be one more important category. I don't really like to ask for it, because i know that TAK performs less well on them...

I added Metallica's Death Magnetic just because it is probably the best known example of hyper-compressed stuff.

Quote
I myself feel comfortable with your cpu choice. While it dosen't support SSSE3, what will make TAK's stronger presets somewhat slower, it's microarchitecture doesn't differ too much from more recent cpus.

Yeah, another complaint might be that I run in 32-bit, while 64-bit is more or less standard these days. Sadly I don't have other machines available. It's either this with Windows XP or the setup as used in the previous comparison. The first results are very, very similar to my 64-bit linux environment (Intel Core2Duo T9600), the only codec that gets a significant performance hit is FLAC's decoding, which is about 20% slower.
Music: sounds arranged such that they construct feelings.

New lossless codec comparison (Jan '13)

Reply #42
I just finished a new revision of this codec comparison. It features new versions of FLAC, TAK, Monkey's Audio, WavPack and OptimFROG, runs on Windows instead of Linux and contrary to what I said earlier, the codecs were run on an AMD A4-3400. Furthermore, the test corpus has been expanded from 29 albums to 43 albums. WMA Lossless is now tested properly, refalac has been added and Real Lossless has been dropped. (edit: OS was Windows 7 SP1 64-bit)

No big changes in the results, except TAK being a whole lot faster.

The PDF and raw results are available here: http://www.icer.nl/losslesstest


Music: sounds arranged such that they construct feelings.

New lossless codec comparison (Jan '13)

Reply #43
It's interesting to see that TAK starts where FLAC stops (decoding vs. compression), it's like they're subsets of the same codec.

New lossless codec comparison (Jan '13)

Reply #44
Fantastic work, many thanks for your time and sharing it, keep it up.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

New lossless codec comparison (Jan '13)

Reply #45
Interesting to see the 4th node of TAK (from right to left) is faster than the 2nd and 3rd node while offering better compression. This renders these two, but especially the 3rd, rather useless IMO. Same counts for the 5th and 6th (7th is better and faster), and the 9th (10th is better).

New lossless codec comparison (Jan '13)

Reply #46
From TAK's Readme:

Quote
Each preset selects a set of internal encoder options. Some of them affect only the encoding speed, the others also the decoding speed.

Slower decoding usually means higher hardware requirements (memory size and/or cpu power) for a playback device. Some devices may be too weak to support the more demanding internal encoder options. But any option, which only affects the encoding speed and complexity, is always applicable.

Therefore each preset consists of two components:
  • The profile selects internal encoder options which affect both encoding and decoding speed. Profiles are declared as a number from 0 to 4 (fastest to strongest).
  • The evaluation level selects only internal encoder options, which have no effect on the decoding speed. The evaluation levels are named Standard, Extra and Max and abbreviated as s, e and m (fastest to strongest).

A hardware manufacturer supporting TAK has only to specify the strongest profile it's hardware can decode, because the evaluation level does not affect the hardware requirements.

Hint: If you want higher compression and fast encoding, and are able to accept some decrease in decoding speed, it is usually preferable to select a higher profile instead of increasing the evaluation level.

New lossless codec comparison (Jan '13)

Reply #47
The CPU used in this test might have been too fast compared to mobile devices to show, but I don't see any big variations in the decoding graph between the mentioned profiles.

New lossless codec comparison (Jan '13)

Reply #48
Depending on the profile TAK is using up to 4, 12, 32, 80 or 160 predictors for it's primary filter. A corresponding number of multiplications per sample has to be performed. FLAC supports up to 32 predictors, but it's restricted subset which is recommended for maximum compatibility is limited to 12 (preset -8). And i remember reports on devices not capable to cope with 32 predictors.

I have no practical experience with the DSPs or cpus used in mobile devices, but from what i have read here at hydrogen and at Rockbox, higher predictor counts seem to be critical.

Indeed the decoding speed results show only a minor effect of the perdictor count, but that's misleading. Reasons:

  • TAK will only use as many predictors as are advantegous. Because not many files benefit from high predictor orders, the average predictor count of the profile p4 might be for instance 70 (or even less) and not 160. But if you want to be able to decode any file without stuttering on a slow device, the device has to be powerful enough to execute the maximum of 160 multiplications in realtime.
  • On a desktop system multiplications are really fast, especially if you are using SIMD instructions like MMX or SSEx. On a mobile device they can be a lot slower.


BTW: I think, TAK could be faster in this test. On the AMD A4-3400 it will only use MMX instructions although SSE2 is supported. Currently TAK will only use SSE2 is SSSE3 is supported too. My fault...

New lossless codec comparison (Jan '13)

Reply #49
Thats a clear explanation. The lack of difference makes sense now. Thanks.