Hi Supacon,

yes TBeck is in contact with Josh - see here:
http://www.hydrogenaudio.org/forums/index....ndpost&p=378368

But when or even if the "Yalac"-method or some parts/ideas of it will be integrated into FLAC or into an other matured lossless encoder stands in the stars.
And I can understand TBeck that he will try to make maximum profit in form of occupational advancement, some kind of academic reputation or even direct commercial profit.

Cya Ryushi

P.S. @TBeck: Ich wünsche Dir viel Erfolg dabei, hoffe aber, dass es letztendlich nicht auf irgend eine patentgeschütze kommerzielle Anwendung hinausläuft, speziell da Du hier einige optimistische "Alphatester" zum Ausmerzen von Fehlern einspannst.

yeah, though not just for the testers, but for the whole community it looks like we stand to gain something useful, and most patents these days do little more than impede progress seemingly :/

I did answer to this via personal mail in german.

It's not my intention to abuse voluntary testers for the optimization of something, which later should become patented or otherwise commercially used.

If this should happen (i couldn't imagine how), i would pay the testers for their work done under wrong assumptions!

Thomas

Good old Google translate:

Sorry, don't mean to be anal, but there is TOS #10. Also, it appears from Thomas' post (I can't grasp the nuance in the "English" above) that your intention was to be conspiratorial.

Anyway, I wish Thomas the best of luck also; it really seems that Yalac could fill a niche: Monkey's Audio compression with FLAC decode speeds. I'm really looking forward to following its progress.

Edit: Also, members should consider the purpose of this thread. General Yalac questions should be posed in the general thread Yalac - Need some testing, (Yet another lossless audio comprossor). (I may later move out posts #5-#10 to keep this thread on topic.)

Hi Synthetic Soul,

pardon me for putting a german post scriptum which would have been better send as a PM at the end of a posting which I better not have posted because I opened the replying mask (and let it open) when reading Supacons question but answered it some hours later when you meanwhile posted your answer.

As TBeck posted he send me a PM answer at my concerns in the post scriptum.

According to google's mutilation, this is hopefully a better translation of my PS:
"I wish you will benefit occupationally from your work [at Yalac], but hope that it [the codec] will not end as a patent protected commercial application especially as you use some optimistic testers to fix bugs/eliminate weaknesses [of your codec]."

Cya Ryushi

P.S. Hope I will not break careless other TOS in the future

Synthetic Soul, I'm finding your lossless codec comparison page very useful as a general reference of codecs. I noticed in the recent lossless codec poll that Apple Lossless Audio Codec (ALAC) is one of the four most popular codecs, but it is not represented in your list.

I'm guessing that there's nothing special about it, but for the sake of completeness, it would be nice to see it in there, if you have a way of testing it, and of course, the time to do that.

I see iTunesEncode will let me encode using ALAC.

I'm not sure how I would decode though. foobar has an unsupported, unstable component which I guess I could use with its "Decoding speed test" function...

I suspect the times are all going to be a bit screwy though: iTunesEncode > iTunes to encode and then a 3rd party decoder...

Does anyone else have any suggestions?

NB: I'm glad you've found my comparison helpful. However, I would reiterate the notes on the initial page: the test corpus is quite limited in scope, and I have only tested what I see to be "yalac-related" encoder settings. What I'm saying is: it's not as comprehensive as it should be. I have actually borrowed some more "diverse" music from my mother (Charlottle Church; Andrea Bochelli; Mozart; some African stuff; ...) with the idea that I may extend or replace my test corpus, but I can't see this happening for a while at the moment.

Be careful with foobar2000's component (and all plug-in based on unofficial decoder): it's significantly slower than iTunes official decoder. On my old Duron, I experienced something near x~20 with foobar2000 (+ entire buffering + high priority + no file writing thus no disk access at all) and something closer to x~40 with iTunes (without high priority + entire file writing etc..).
iTunes decoder is much more optimized and it wouldn't be fair IMO to base the speed measurement on the weakest implementation.

Well... I know that you'd rather be all scientific, but perhaps just using a stopwatch would work fine, just to get a general idea of its relative performance (but note this inaccuracy with an asterisk or the like).
I guess it is a rather large encoding job though to do it that way.

Thanks guruboolez. If that's the case I won't use it.

I don't really see how I can accurately represent it then.

Yeah. I am only interested in accurately representing an encoder. I am also only interested in setting a job going and doing something more interesting while it all happens. My previous tests have track-accurate results, where decoding times can be a matter of a few seconds. That would be a tortuous exercise, and I would produce hideously inaccurate values with my barely opposable thumbs and a digital watch from Argos.

If I had to do again a lossless comparison (with decoding speed measurement), I'd introduce two values:

- foobar2000 decoding speed tool (really excellent, but not available for every format and not necessary representative¹ of the true capacities of the supported format)

- official decoding software (CLI or audioplayer) by using either a chronometer or a dedicated software²



¹ BoraBora discovered that foobar2000 0.83 results for various formats were significantly slower than a simple CLI decoding. I also quickly noticed that foobar2000 0.9's optimisations lead to increase the speed for various format (from x48 [0.83] to x60 [0.9] with the same files on the same computer) but maybe not for all of them (I'm not sure that Money's Audio benefit from the same progress). It seems obvious that foobar2000 could be used as accurate methodology (multiple pass, buffering, no impact of fragmentation or medium speed...) but the speed themselves are maybe biased by the level of optimisation of each component library [I recall: it's just a supposition]

² Is there something better than TimeThis.exe? I discovered it recently and I wonder if better software exist.

Including the foobar Decoding speed test report for each decode would be nice. However, if you believe that it "favours" some codecs over others it may again not be representative - or only representative of a foobar decode, which may actually be merit enough.

I used TimeThis to obtain my calculations. I had a separate folder for each setting, into which went the encoded and decoded files. Each folder had encode.bat and decode.bat in them. encode.bat recorded the output from TimeThis in a text file (encode.txt), and also recorded the generated file sizes in another (size.txt). decode.bat recorded the output from TimeThis in a third text file (decode.txt). I then used a Windows Script file to scrape the "Elapsed Time" values from the TimeThis logs (encode.txt & decode.txt), grab the list of file sizes from size.txt, and insert all the data into the database.

NB: I also have an earlier version of the Windows Script file that simply scrapes the "Elapsed Time" values and outputs them to yet another text file (one time per line), if it is of use to anyone.

There are a few things you could do, if you want to test ALAC : first of all, when using a stopwatch, use your index finger : it'll be quicker (I've timed swimming comptetitions...)

You can time a small group in itunes decoding, and time your large group with foobar or another tool, using timethis : Then, you compare the decoding speed from itunes to foobar, and apply a normalization on the decodings over the whole collection of foobar decoded files.

If you have 4NT (from JPSoftware), you can bracket command lines e.g. :



Resolution is down to 0.01 seconds.