The unusually useless case of loadCompressedDataFromByteArray

As you might probably know Tetragon uses zipped resource packages that are used by it’s AIR builds. These resource packages contain all the asset files, which can be images, XML files, SWF files, etc. etc. and also MP3 files. The only way to load MP3 files directly with AS3 so far has been to use Sound.load() but in the case of Tetragon MP3 files need to be loaded as raw byte data since this is the only way how it works to read  MP3 files that are stored in a packed zip file (remember Tetragon streams in data from zip files via random access, which is quite cool and something I explained here).

Since the AS3 Sound class had no methods to accept any byte data the workaround to load MP3 files as raw byte data so far has been to load them with URLLoader and then wrap the MP3 data into an in-memory SWF that is created with the help of AS3SWF. This works fine on desktop- and on Android builds. But enter iOS where it’s strictly forbidden to execute any non-native scripts and the whole idea falls apart as not even the creation of an in-memory SWF structure is allowed there, you will simply get an exception thrown and end up with no sound in your application.

However with the release of Flash Player 11 and AIR 3 there was a promising solution for this problem glittering at the horizon of Flash development: two new methods for the AS3 Sound class named loadCompressedDataFromByteArray and loadPCMFromByteArray! This new API was something I’m sure many audio-related Flash devs have been looking forward to since a long time and so I too was looking forward to finally be able to change the audio file loading in Tetragon to something that is natively supported and works on all supported platforms.

The disappointment was great when I sat down to implement the new sound API, in particular loadCompressedDataFromByteArray which as the (very terse) API documentation claims can be used to load MP3 files into the Sound class as byte data, just as we need it. In truth this obviously means that an MP3 file can be streamed in with this method and it’s audio played back only IF it’s played right after a call to the method. Trying to keep the loaded audio and play it back later results in an invalid Bytearray. This is how it’s done here. Check the onComplete handler in the script and you see how loadCompressedDataFromByteArray() is called and right after it sound playback is started. If you would try to play the sound later it’s not going to work. The audio data is lost!

UPDATE: I have filed this bug on Adobe’s new bug base! Please follow the link and vote for it! https://bugbase.adobe.com/index.cfm?event=bug&id=3072682

So either the new sound API is completely bugged or way too limited to make good use of it. There has been similar complaints from Andre Michelle about the other new method, loadPCMFromByteArray which seems to be quite buggy. Read more about it here http://bugs.adobe.com/jira/browse/ASL-281 (and please do log in and vote for the issue, if you can!). Unfortunately Adobe’s so called Bug and Issue Management System seems to be quite bugged by itself. I’ve been trying to register there, by now with three different Email addresses but never got any confirmation Email back from them, so I can’t log in. Trying to contact the admins doesn’t work either. Clicking the “contact the administrators” link will result in the following adequately useless page:

Find any admin link there? Right, me neither. Seems Adobe doesn’t want to be bugged about bugs, haha.

This is all a very sad state of affairs! whoever implemented (unplemented suits better here) the new sound API was either not given any time to finish it, or had absolutely no sense or concept on how to do this right. Seems it wasn’t even tested properly. If you can please go to Adobe’s Bug report site and make some noise about this! There is a lot of potential in the new sound API, if it only would work!