audio wave

How to create audio files with different specifications

One of the most basic methods to create audio files with different bit depths, sample rates and bit rates is by converting a high-quality track into different file formats with particular characteristics.

The reason for using a high-quality track is that most audio formats are compressed. You can compress a high-quality file (which then, loses some of its quality), but you can’t turn a compressed file into a high-quality uncompressed file for real – you can’t extract data from there’s too little or none. 

If you only wish to test file compatibility issues, then there’s no need to use an initial high-quality track as the audio fidelity will be of no concern. This is only important for pure audio testing where every single hearable detail is essential.

In this article, we suggest using a free, open-source piece of software called Audacity. It is fairly easy to use and has little to no limitations regarding what we’re set here to do. 

The process is simple and for it we will use a high-quality WAV file:

  1. Open the desired track in Audacity;
  2. Click File – Export – Export Audio;
  3. Click the Save as type section and, for example, click MP3 Files;
  4. At this step you are presented with a few options about the Bit Rate Mode, Quality, Variable Speed and Channel Mode; the recommended settings are “Constant” Bit Rate Mode, 320 kbps Quality and Stereo Channel Mode; click SAVE;
  5. For other file types, like WAV, you just select the bit depth in “Save as type”;
  6. For other uncompressed files, select it in “Save as type” and under Header you can find different uncompressed formats, but this is a more advanced feature.

Elements to test:

Access & Interface

On most devices, starting an audio app for the first time should be met with a message asking the user for permissions to access at least the storage. Any good audio app should also have a user-friendly interface, clean and with elements that are easily seen (like the play/pause, previous/backwards and next/forwards buttons) and also respond fast to user input. The playlist in which the audio files are displayed should contain all the compatible files on your device, which should load very fast (or instantly). If such a thing is not possible, on slower devices, a loading sign should be shown to inform the user of what’s happening. Most audio apps have a Settings button which should offer some options like an equalizer, theme or type of playlist view, as well as an About button and maybe a Send Feedback one. Some apps, like Pi Music Player for AndroidOS, also have the potential to change what’s displayed in the playlist, based on Tracks, Folders, Albums, Artists, Genres etc.


In this section, testing must be simply focused on checking if whatever is shown in the interface, works as intended. For example, tapping the Play/Pause button should not stop the playback – that’s reserved for a dedicated Stop button. Most apps will restart the song if the user taps once on the Previous button and jump to the previous song if tapped twice. Other elements that testing should also focus on are the seeking bar and effects button(s) if there is such a thing. Scrolling the playlist should have a fluid motion and if the Next button is tapped while the last song in the playlist is running, the playback should jump to the first file on the list. 

Jumping between songs either by randomly tapping on files or by using the in-built buttons of the app should also be tested as sometimes crashes can occur after stressing the app too much. 

The Search function has a particular field of its own, as there are a multitude of tests that can be done on it, ranging from how accurate is this function to how fast can it work.

Another idea for testing is to leave the app play in the background for 30-60 minutes or more and check if anything unusual happens; the app might crash, the playback might stop, effects (if any) might get disabled or enabled on their own etc. 

When using a pair of AUX headphones or a BT speaker connected to the testing device, the tester should check how the output changes when these peripherals are disconnected/reconnected – what happens to the sound and the playback. 

These are just a few ideas for this section of testing.

File compatibility

We previously talked about audio file formats and their most important specifications: sample rate, bit rate and bit depth. First of all, testing audio files should begin by ensuring which (if not all) of the files on your device are recognized by the app; this is done by checking if the files you copied on your device actually appear in the app’s playlist. 

This might be the first step in file compatibility testing. For ease of use, the test tracks can be named based on their specs, e.g. “44100-16-320.mp3”, in this case meaning that the file has a 44100 Hz sample rate, a bit depth of 16bit and a bit rate of 320 kbps. 

Next step involves playing the files, one by one and usually listening to more than 10-20 seconds of each. In some cases, bugs can cause the files to stop after a few seconds. 

If some files have artworks and the playlist allows for a grid view, check for these artworks to be displayed correctly. 

In rare cases, some files may not be seekable by use of the seeking bar – this may not necessarily be a bug as files that don’t have a constant bit rate can pose problems to the developers. 

More test suggestions are that of files with special characters in their names, very large files (2, 3, 5+ GB) or very long audio files (2, 3, 5+ hours). These should be able to run without any issues. 

Audio fidelity

This may be the step where the tester’s ears are needed the most. An app that cannot render an audio file cleanly is of no use to anybody. Each test track should be tested on the device’s internal speakers, using a pair of headphones connected by cable via AUX and by use of a Bluetooth speaker if your device has such capabilities. 

Testing should be focused on how clean the audio files appear to be. Check for stuttering, distortions, artifacts (sounds that should not be there), inconsistent playback speed etc. These tests presume that you, as a tester, are intimately familiar with the test tracks you use and know how they sound on a perfectly working application. Anything added to (or subtracted from) the test tracks can represent a potential bug. 

Although an untrained human ear cannot detect any differences between a 256 kbps and a 320 kbps audio file, files with bigger differences can be spotted easier. A 44100 Hz/320 kbps song and a FLAC one should not be very hard to differentiate for the tester, if provided with a hi-def pair of headphones. 

If the application has an equalizer or a set of effects like 3D sound, enhanced stereo, reverb etc, these should also be tested thoroughly and made sure they work in any condition, especially if the app is stressed or enabling/disabling such effects is spammed (turned on and off rapidly).

In certain situations, some effects may cause clipping of the audio file, meaning that it might get distorted because of too high a volume. These may not always be bugs if the effects have adjustable settings; if not, that should certainly not happen to a clean, normalized audio file.

The tester should also try to see what happens if another audio app is started on the device while the tested app is playing a song or if external sounds are played (like a notification sound, a message or an incoming call happen).

 There are many types of tests that can be done on an audio application, as the suggestions presented here cover only the most basic of aspects. The more complex the app, the more work a tester has to do to ensure that the product is suitable for release and compatible with the owner’s requests.

This concludes the main ideas about the practical aspects of testing an audio application for tablet or mobile.