I want to know if it is faster to load and play a small wav than a small mp3 file on android media player. The wavs are about 30 KB and the same files as mp3s are about 20 kb. The mp3s have the advantage to save resource space. The sound files have to be played with split second timing.
For such small sounds, you will get best results with SoundPool.
Even the weakest android devices have ample computing power to play an mp3, and probably have hardware acceleration for it as well. The real question is the setup overhead for playing a wav vs. playing an mp3, which should be fairly easy to measure programmatically.
I'm a little surprised you're getting such a poor compression ratio with mp3. Even lossless compression algorithms tend to get a 2:1 compression ratio with wav. Given that an android device probably isn't hooked up to audiophile-quality speakers, you should be able to get away with 64 kbit/s mono mp3 compression, or even lower. If you can get the file size under 4K, it'll fit in a single memory page, which is about as low as you can get for OS overhead.
If for whatever reason you're stuck with a 1.5:1 compression ratio, it's probably not worth the extra work.
Wav files use more space because they have a higher sample rate. Pretty much more points that the sound wave will trace out so in theory it would take more processing power to play a wav. Also wave is uncompressed meaning it has all of the information from the source it was taken from. When you take a cd and convert it to wav you more or less have a copy of the original. When you convert to mp3 it uses fewer reference points and detail is lost. Secondly, most mp3 encoders normalize the music which is a fancy way of saying it makes the quiet parts louder and the loud parts quieter. All this being said some people cant hear the difference and it mostly depends on what type of headphones/speakers you are listening on... ALLL that being said there shouldn't be a delay on either format the only difference should be the sample rate or "resolution" of the sound file
I have no technical "stuff" to back me up here, but since no one else has taken a crack at this, I will.
I know that mp3s have "better" compression than wavs, thus the file is smaller. This would imply, however, that it would take more cpu to "uncompress" the files. (This may be done on dedicated hardware so it could be a moot point.) Additionally, since the files will be inflated, it may be deceiving to see the mp3 file's smaller size and think it would be quicker to load and play.
Considering the wav file format's history, and that it serves as a 'lowest common denominator' when it comes to exchanging sound files between different programs (per Wikipedia), I would make an educated guess that it would be faster to load and play a small wav file. This is very dependent on Android's software implementation of audio libraries as well as the hardware so if anyone knows more, it would be great to hear their take.
Related
I have started a android.media.MediaPlayer file with:
mp1.start()
and then trying the looping with:
setLooping(true);
but this is ending up with a delay in playing the file again.
I am trying to run an mp3 file containing a rhythm with a set tempo. Is there any better way of looping it in such a manner that the tempo timing does not get disturbed and the rhythm plays seamlessly without any stutter/delay?
Should I use SoundPool instead?
Most of best practices for this particular case recommend using .ogg format. You can convert you file easily using VNC media player.
Wiki for .ogg file format - http://en.wikipedia.org/wiki/.ogg
Another solution is the SoundPool and the third one - is to use Audacity and cut the quiet/“blanksound” from you audio file.
If your audio is not long, then use SoundPool for low-latency media playback, instead of MediaPlayer. Also convert it to ogg, as others have already pointed it out.
Edit: if it is just a tempo, and not a continous sound, then maybe you can also measure the latency and seek your audio based on that, but I am not sure you will get better results this way.
Mediaplayer solutions:
If you insist on using MediaPlayer, then you can:
either crop the sound at the end of your audio files, so there's no sound gap between two playback loops
or create a custom solution yourself as the one described here.
Soundpool alternative:
Now, from my personal experience, if you want to loop files small in size and duration, not more than 1MB, then Soundpool is more convenient and it seems that not any relevant problems are reported in contrary to the MediaPlayer. There have been many complaints when trying to loop sounds using MediaPlayer, so generally Soundpool is usually preferred for looping.
Soundpool size limit:
If you are concerned about Sounpool's size limit, keep in mind that it has 1Mb buffer size limit per track. But this limit applies not to file size but to decompressed raw PCM data. SoundPool is going to decompress the loaded audio to PCM data so it is ready to play instantly without the latency of decoding. If the audio you are loading is compressed heavily, such as MP3, then that can get blown up quite a bit.
Improve performance:
Also, as suggested in another answer, files of type ".ogg" according to many sources appear to perform better than ".mp3" in general. So, you should try to convert your files for better performance, but I don't think you will see an improvement concerning looping.
To convert your files you can use an online tool such as this. If you convert your files remember to also make these changes:
Change your sound file's sampling rate to 16000 Hz
Change your audio channel to mono, instead of stereo.
Make sure your file after these processes is smaller than 1 mb in size.
Please try to do it this way.
audio = MediaPlayer.create(this, R.raw.pl);
audio.setLooping(true);
audio.start();
I'm playing mp3 file streamed from the network in my application, some mp3 files has weird behavior: mediaPlayer.getCurrentPosition() is larger than mediaPlayer.getDuration() at the end, for about 3 seconds.
The mp3 files are CBR encoded.
What might be the reason of this?
Finally solved the problem by converting the mp3 files, this is the command I'm using:
lame --mp3input -t -m s -b 128 --cbr input.mp3 output.mp3
There is a few reasons you can get this behavior.
First it appears that people had better results using mp3 files at exactly 44100Hz, because apparently the MediaPlayer class is assuming this value and scale the time accordingly, making strange values for files not using this sampling.
You also need to check the mode of your channels, and try using Joint Stereo or forced L/R Stereo. Joint should be the default, but your files might have been previously bad encoded, so it's worth trying. It's interesting to note that Forced L/R Stereo might loose quality for the same bitrate as Joint.
It would also be useful to check the output of soxi which is part of the sox package (you can also do it with ffmpeg), that will give you the number of channels, Sample rate, Bit Rate and Number of Channels.
Also you might want to check the raw content of the mp3 file if you did some treatment on them using any app for the presence of garbage xml content that might have been inserted during the export.
If you have the possibility to modify the mp3 files you're streaming, (which sounds like you do since you can tell the bitrate) these are what I would try first. If it's more like user-upload kind of stuff, maybe you should have a look to another solution instead, like ExoPlayer which has a few thousands stars and active development. It wraps the MediaPlayer api still, but worth a try.
You also have to consider that it might be a threading problem, where the player would stop playing, but the timer would actually keep going, giving you this result where it's superior to the actual duration of the song. 3 seconds seems a bit too much to explain it by that, but that's just a thought.
I create around 1000 audio files via sox for my android application, each containing a recording of a word. To safe space I want to keep the file size as small as possible.
Should I use .mp3 or .ogg? Which settings should I use?
Have you checked that question on SO Smallest audio file: MP3, Ogg, or Wav? ?
#keyboardP said:
Of those three, Ogg would usually be smaller than MP3. Both would be
much smaller than the uncompressed WAV. Of course, there may be other
factors that come into play for your site such as quality (not too
much of a noticeable difference for most purposes) and browser support
for each type.
The file size will only affect the time it takes to download the file
to the user's machine. It won't necessarily determine Javascript
execution speed. There may be other things in your code causing the
performance drops (unless you've narrowed it down to the file size of
the audio files).
If little loss in quality doesn't affect your application than using audio-grabber to decrease the bit-rate of .ogg files will give you amazingly small audio files.
Since Android supports both of the codecs natively I would definetly choose the Vorbis codec. At low bitrates the Vorbis codec produces a much higher clarity than MP3 and even the file size is smaller.
In general I would recommend to encode the sound files with the aoTuV encoder (which is a third-party development of the official Vorbis encoder which further improves low bit-rate quality) in quality level 1 (approximately 80 kbps).
I have a lot of small .ogg sound files (average size of ~35-50KB) that I need to have played from my AWS S3, and then once played, they need to be cached on the device. There are approximately 200 sounds, and that is 1/10th of what the finished application will use.
I'm not sure the Stagefright library is my best bet, or if an entirely different approach is needed. Should I use Stagefright, or go with another option???
From your query, I feel that you could use SoundPool for your application. Please refer to this link SoundPool for more information.
A couple of examples can be found in MediaActionSound.java, SoundPoolTest.java and Soundclips.java.
I'm currently working on an app that lets the user choose an MP3 audio file. The file is then processed by my app.
For this processing, the application would need to decode audio files to get the raw PCM output.
To decode MP3, I have two options:
Use the Android system to decode MP3 and get the PCM data.
Decode the MP3 myself on the phone, WITHOUT paying MP3 licensing fees.
My question is whether #1 is technically possible? And for #2, whether the MP3 license on the phone covers an app as well?
To my knowledge, there is no Android-provided way to decode MP3s.
I've used JLayer in the past, and can recommend it for MP3 processing. Using the NDK with a c++ library might be faster, but if you're looking to keep it Java, that's what I'd use. It's still faster than real-time, roughly 30 seconds to decode all frames in an average bitrate 3 minute MP3. That's with an Galaxy S(1GHz), so any newer phones are faster.
As far as licensing goes, I can't help you there. JLayer itself is LGPL, but the world of MP3 licensing is murkier than used motor oil. After a few days of searching for a concrete answer, I just gave up and did it. The world at large seems divided on who even holds the license in the first place.
the Android system can decode mp3 file now, see here it describes the media codec, container, and network protocol support provided by the Android platform.
The MedieCodec is a very powful framework to encode and decode media file.
Option 1 is definitely not possible (unless you want to target ICS+ devices and are willing to write native C code to decode MP3s with OpenSL). Geobits recommendation of jLayer is a good one. For the most part, dealing with jLayer is a breeze. Here's a good blog post that will help: http://mindtherobot.com/blog/624/android-audio-play-an-mp3-file-on-an-audiotrack/