5 ms·

Apple Lossless Decoder in Coffeescript

81 points by jensnockert 15y ago

joncooper 15y ago
I enjoyed reading this source, and will probably use your Buffer/Stream classes in a project I'm working on. Thanks!
- jensnockert 15y ago
  You're welcome!
devongovett 15y ago
See a demo here: http://codecs.ofmlabs.org/ http://codecs.ofmlabs.org/
jashkenas 15y ago
@devongovett: Have you considered pushing the annotated source for this to your "gh-pages" branch? It would make for a great read.
- jensnockert 15y ago
  Would take quite some time annotating the source, not really our first priority. (We have more codecs on our hitlist) But if someone wants to do it, I think both me and @devongovett would be ready to help out a bit. (We usually hang out in #ofmlabs on freenode, if someone wants to speak with us)
- devongovett 15y ago
  We could do, although there aren't that many comments... Not sure it would help much at this point.
tlrobinson 15y ago
devongovett/jensnockert: what was your experience with using CoffeeScript for such low level code? Did you need to consciously avoid certain CoffeeScript features that could negatively impact performance?
- jensnockert 15y ago
  Mostly avoided the regular for loops, replacing them with `for ... by 1`, to make sure the compiler knows in which direction to iterate. Otherwise it is pretty similar to javascript, most coffeescript constructs map pretty simply down to javascript, so optimization tips for one language mostly applies to the other.
- devongovett 15y ago
  Overall positive, but as with any programming language, you have to be careful sometimes. For example, the for loop in CoffeeScript can be slow if you aren't careful: for i in [0...10] doSomething() is slower than for i in [0...10] by 1 doSomething() because of the way it is compiled, so we always include the `by 1` as an optimization. Another one is that if you have a function and the last thing in that function is a loop of some kind, CoffeeScript will try to return an array from that function collecting the results of the loop. So we explicitly put a return statement at the end of the function to avoid this and the performance penalties. There are probably a few more to be careful of, but overall performance characteristics are similar to JS. I'm sure Jens has some thoughts too, but overall I think it was a positive experience.
  - jbanon 15y ago
    This is the difference in compiled output for those examples: var i; for (i = 0; i < 10; i++) { doSomething(); } for (i = 0; i < 10; i += 1) { doSomething(); } http://jashkenas.github.com/coffee-script/#try:for%20i%20in%20%5B0...10%5D%0A%20%20doSomething()%0A%0Afor%20i%20in%20%5B0...10%5D%20by%201%0A%20%20doSomething() http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...
    - devongovett 15y ago
      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 ? i < test : i > test; 0 <= test ? i++ : i--) { doSomething(); } for (i = 0; i < test; i += 1) { doSomething(); } the latter one being much faster because it isn't testing the direction the counter should be going all the time.
neimado 15y ago
what a shame you chose to do this in Coffeescript. Would have looked much more beautiful if written in JavaScript.
swaits 15y ago
Wow! Great work!
ditoa 15y ago
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/ 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 code (or a bug in Chrome (16-stable) that I used to check out the demo site)?
- devongovett 15y ago
  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! :)
Andi 15y ago
Stop wasting your time by rewriting existing JavaScript implementations in other languages that compile to JavaScript!
- jensnockert 15y ago
  Hm..? The only ALAC implementations we know of is the Apple one (in C++), David Hammerton's one in C, and ours in Coffeescript.

81 points by jensnockert 15y ago

joncooper 15y ago

I enjoyed reading this source, and will probably use your Buffer/Stream classes in a project I'm working on. Thanks!

jensnockert 15y ago
You're welcome!

devongovett 15y ago

See a demo here: http://codecs.ofmlabs.org/ http://codecs.ofmlabs.org/

jashkenas 15y ago

@devongovett: Have you considered pushing the annotated source for this to your "gh-pages" branch? It would make for a great read.

jensnockert 15y ago
Would take quite some time annotating the source, not really our first priority. (We have more codecs on our hitlist) But if someone wants to do it, I think both me and @devongovett would be ready to help out a bit. (We usually hang out in #ofmlabs on freenode, if someone wants to speak with us)
devongovett 15y ago
We could do, although there aren't that many comments... Not sure it would help much at this point.

tlrobinson 15y ago

devongovett/jensnockert: what was your experience with using CoffeeScript for such low level code? Did you need to consciously avoid certain CoffeeScript features that could negatively impact performance?

jensnockert 15y ago
Mostly avoided the regular for loops, replacing them with `for ... by 1`, to make sure the compiler knows in which direction to iterate. Otherwise it is pretty similar to javascript, most coffeescript constructs map pretty simply down to javascript, so optimization tips for one language mostly applies to the other.
devongovett 15y ago
Overall positive, but as with any programming language, you have to be careful sometimes. For example, the for loop in CoffeeScript can be slow if you aren't careful: for i in [0...10] doSomething() is slower than for i in [0...10] by 1 doSomething() because of the way it is compiled, so we always include the `by 1` as an optimization. Another one is that if you have a function and the last thing in that function is a loop of some kind, CoffeeScript will try to return an array from that function collecting the results of the loop. So we explicitly put a return statement at the end of the function to avoid this and the performance penalties. There are probably a few more to be careful of, but overall performance characteristics are similar to JS. I'm sure Jens has some thoughts too, but overall I think it was a positive experience.
- jbanon 15y ago
  This is the difference in compiled output for those examples: var i; for (i = 0; i < 10; i++) { doSomething(); } for (i = 0; i < 10; i += 1) { doSomething(); } http://jashkenas.github.com/coffee-script/#try:for%20i%20in%20%5B0...10%5D%0A%20%20doSomething()%0A%0Afor%20i%20in%20%5B0...10%5D%20by%201%0A%20%20doSomething() http://jashkenas.github.com/coffee-script/#try:for%20i%20in%...
  - devongovett 15y ago
    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 ? i < test : i > test; 0 <= test ? i++ : i--) { doSomething(); } for (i = 0; i < test; i += 1) { doSomething(); } the latter one being much faster because it isn't testing the direction the counter should be going all the time.

neimado 15y ago

what a shame you chose to do this in Coffeescript. Would have looked much more beautiful if written in JavaScript.

swaits 15y ago

Wow! Great work!

ditoa 15y ago

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/ 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 code (or a bug in Chrome (16-stable) that I used to check out the demo site)?

devongovett 15y ago
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! :)

Andi 15y ago

Stop wasting your time by rewriting existing JavaScript implementations in other languages that compile to JavaScript!

jensnockert 15y ago
Hm..? The only ALAC implementations we know of is the Apple one (in C++), David Hammerton's one in C, and ours in Coffeescript.