If this is the one you want to use then Ill get my info stuff more robust and then Ill see if/how they want to add it You are not spoiling anything. And if its going to use an arraybuffer I could add even more optimisations if they want. On speed, Ive noticed a couple of things in that code that could be speed up and Ill prolly do them at some time. So Ive patched it to be able to use an arraybuffer (Ill send them a pull request later), so now it doesnt have to reproduce the file once again, plus itll be quicker.
The only real problem I saw for your needs was that it was using a string to hold its binary data and that meant youd have to first convert your mp3 to a string which is dumb considering your already have it as arraybuffer. Ive been looking at it and its real good, but I cant test on other devices as I dont own any and so cant comment on that. But now Ill go and look around and see what else needs adding to make it more complete.Īt some point your going to need this stuff and was wondering if you still think.
I wrote that just by looking at the specs and not other peoples code (except the lookup tables, im lazy) so as to avoid having to use their us it was a real fun challenge. Plus Ill be extending it and making it do more like error checking (sooooooo boring).
First up that code I put up for reading header info failed on a couple of files, but pretty sure I know why and it will be fixed in the next couple of days.
0 kommentar(er)
