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.
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 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).
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.
...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?
Quote from: spicymeatball77 on 05 April, 2013, 09:26:13 AMI'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.
Flac -8: 16:09:49Wv -hh -b384x: 11:17:12mp3 v0: 11:48:20vorbis q5: 12:17:56opus 160: 10:17:00
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.
I use timer.exe from 7-Benchmark: http://sourceforge.net/projects/sevenmax/files/7-Benchmark/
just yesterday i was wondering if there was a tool for benchmarking command line programs and i found this.
I hope this time your Windows computer can run flacCL. Would be nice to see it included.
Yes, I saw that one too, but the problem is it reports running time, not CPU time used.
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.
I thought that "Process Time" is CPU time. What is the difference between them?
What CPU does it have and what instructions does it support (SSE, SSE2, etc.)?
processor : 0vendor_id : AuthenticAMDcpu family : 15model : 36model name : AMD Turion 64 Mobile Technology ML-34stepping : 2cpu MHz : 1800.141cache size : 1024 KBfpu : yesfpu_exception : yescpuid level : 1wp : yesflags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pgemca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_optlm 3dnowext 3dnow rep_good pni lahf_lmbogomips : 3600.28TLB size : 1024 4K pagesclflush size : 64cache_alignment : 64address sizes : 40 bits physical, 48 bits virtualpower management: ts fid vid ttp tm stc
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.
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.
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.
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 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.
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.