What's the best strategy for a large amount of audio files in a mobile app?
I have an S60 application that I am writing in Qt that has a large number (several thousand) of small audio files attached to it, each containing a clip of the spoken word. My application does not require high fidelity sound reproduction, but even at the lowest bit rate and in mono MP3 format, they average 6K each. This means that my application can have up to 10 MB. The nature of the app is such that only a few audio clips are needed at any given time - maybe up to 50, but more like 1-10.
So my question has two parts:
1) - 10 MB for too large a mobile application?
2) what is a reasonable alternative to deliver all audio files during installation?
thank
source to share
In terms of persistent storage, 10Mb is not very much for modern mobile devices, so - after downloading - saving your app data on the device shouldn't be a problem.
Another type of footprint you might want to consider is memory usage. Ideally, you should have clips buffered in RAM before starting playback to minimize latency. Given that most Symbian devices impose a default heap size limit of 1Mb, you cannot keep all clips in memory, so your application will need to manage loading and clearing the cache.
It is generally not possible to simultaneously save multiple compressed clips on Symbian, since buffering a clip usually requires the use of a scarce resource (namely an audio processor). Opening a new clip while another is already open will usually cause the first to close, which means you can only buffer one of them in memory at a time.
If you need to reduce latency, your application will therefore have to take care of loading and unpacking when needed in order to provide PCM, which can then be pushed onto the audio stack.
source to share
Have you considered rolling all the clips into one file and then searching the stream? I'm not sure how many overhead files there are in the file, but it might help.
However, every S60 mobile phone out there needs to have 1 GB or more, so 10 MB doesn't sound too much. But you have to deliver the application as a JAR file that people can download from your site from a PC and then install over the cable. Downloading large amounts of data over the phone is quite expensive in itself in many parts of the world (eg Switzerland).
source to share
10MB is definitely on the big side. Most applications are <1MB, but I think I've seen some large ones (6-10-15 MB) like dictionaries.
Most S60 phones have about 100MB of phone storage space, but they also have memory cards and these are usually 128MB +, with 4GB not uncommon for higher end phones. You need to check the specifications for your target phones!
Having such a large installation package would make the above air installation prohibitively high. Try to combine the files so that you only have a few large files instead of many small ones, or the installation will take too long.
An alternative would be to send the most frequently used sounds and download the rest as needed. The S60 has security checks and you will need to grant special permissions to the app when signing it.
source to share
Store audio files in a SQLite database and access them only on demand. It looks like you are writing a vocabulary dictionary. Keep the app as small as possible. This will make it easier to download the application by comparison. As the database market matures, it seems that the developer needs to know more about two database engines: SQLite, for desktop and pocket applications for maximum performance, and MySQL for huge multi-user databases. Do not load all these startup sounds unless critical. Microsoft Bookshelf '96 violin is still my favorite speaking vocabulary app; do not joke.
source to share
- 10 MB for a mobile app is not too big, you convince the user that the content he or she is going to be pulling over the air is worth charging the users.
Symbian as a platform can work well with this application as the actual audio files will be delivered from the SIS file, but the binary will not contain them and therefore will not cause memory problems ...
- The best option is to provide the media for uploading through your site so that the user can upload and sync them through the PC-Suite / Mass Storage transfer. Allow the user to upload files to e: \ Others or some public folder and offer to read information from there ...
My 2cents ...
source to share