Live data from Hacker News

Apple Lossless Decoder in Coffeescript

github.com

21–26 of 26 posts

Re: Apple Lossless Decoder in Coffeescript

#21
post #20

Perhaps I am missing something obvious here (very possible as I do not work with audio decoding) but the demo at http://codecs.ofmlabs.org/ appears to playback the MP3 (not tested the ALAC file yet) too quickly. The site reports the MP3 as lasting 4:25 whereas manually downloading the track from the above website Winamp says the track is 5:14 long and playback is noticeably slower. Is this by design or a bug in the c…

Well technically it is a missing feature in Chrome that we tried to work around to varying degrees of success. The Chrome audio API has no way to change the sample rate and uses whatever the native hardware sample rate is. We didn't have time to finish implementing sample rate conversion in JS (but it is coming) so we cheated a bit by dynamically loading a different file based on some common hardware sample rates. It seems that sometimes Chrome reports the sample rate wrong or something though, and we have seen this issue at least once before and will be looking into it and reporting browser bugs accordingly. Rest assured that this was just a hack, and real sample rate conversion is JS is coming along soon! :)

Re: Apple Lossless Decoder in Coffeescript

#22

Earlier quoted context omitted.

Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 test; 0 the latter one being much faster because it isn't testing the direction the counter should be going all the time.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

[deleted]

Re: Apple Lossless Decoder in Coffeescript

#24

Earlier quoted context omitted.

Oops, I should have written it using a variable instead... i.e. for i in [0...test] doSomething() for i in [0...test] by 1 doSomething() compiles to: var i; for (i = 0; 0 test; 0 the latter one being much faster because it isn't testing the direction the counter should be going all the time.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

I've programmed in dozens of languages, and I can't think of another one where loops could automatically run either up or down depending on the start and end values.

Not knowing CoffeeScript well, when I see this code:

n = -10 for i in [0...n] doSomething()

I'd expect it to call doSomething zero times. At least that's what I'd expect in JavaScript or any of the other languages I've used.

Re: Apple Lossless Decoder in Coffeescript

#26

Earlier quoted context omitted.

This is one of the grayer areas. After your experience writing this decoder ... would you prefer CoffeeScript to keep its loops that can go in either direction, or would you prefer loops to always iterate upwards, and have to be explicit if you'd like to count from "[100..1] by -1" ?

I've programmed in dozens of languages, and I can't think of another one where loops could automatically run either up or down depending on the start and end values. Not knowing CoffeeScript well, when I see this code: n = -10 for i in [0...n] doSomething() I'd expect it to call doSomething zero times. At least that's what I'd expect in JavaScript or any of the other languages I've used.

I agree with you at least 40%, and that's originally how CoffeeScript behaved. Would you still feel that way if you had explicitly written:

    for i in [10..0]
I've opened a ticket to discuss this further: https://github.com/jashkenas/coffee-script/issues/1952
Post reply on HN