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 to different file formats.
The reason for using a high-quality track is that most audio formats are compressed. You can compress a high-quality file (even if it loses some of its quality), but you can’t turn a compressed file into a high-quality, uncompressed file – you can’t extract data from where there’s too little or none.
If you only want to test file compatibility issues, there’s no need to use an initial high-quality track. The audio fidelity will be of no concern. This is only important for pure audio testing, where every single hearable detail is essential.
We suggest using a free, open-source piece of software called Audacity. It’s easy to use and has little to no limitations.
We’ll start by using a high-quality WAV file:
- Open the desired track in Audacity.
- Click File – Export – Export Audio.
- Click the Save as type section and, for example, click MP3 Files.
- You have a few options with this step 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.
- For other file types, like WAV, you select the bit depth in “Save as type.”
- For other uncompressed files, select it in “Save as type,” and under Header, you can find different uncompressed formats (this is a more advanced feature).
Here are the elements you need 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 permission to at least access the storage.
Any good audio app should also have a clean, user-friendly interface, with easily seen elements (like the play/pause, previous/backwards, and next/forwards buttons). It should also respond fast to user input.
The playlist where 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 isn’t possible on slower devices, a loading sign should inform the user of what’s happening. Most audio apps have a Settings button with options such as equalizer, theme, or type of playlist view. It also has an About button and maybe a Send Feedback one.
Like Pi Music Player for AndroidOS, some apps can also change what’s displayed in the playlist based on Tracks, Folders, Albums, Artists, Genres, etc.
Testing must be focused on checking if what’s 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 you tap once on the Previous button and jump to the previous song if tapped twice.
Other elements that testing should focus on are the seeking bar and effects button(s). Scrolling the playlist should have a fluid motion. If the Next button is tapped while the last song is running, the playback should jump to the first one.
Jumping between songs by randomly tapping on files or using the app’s in-built buttons should also be tested. Sometimes crashes occur after stressing the app too much.
The Search function has a particular field of its own. Many tests can be performed, ranging from how accurate functions are to how fast they can work.
Here are some testing ideas:
- 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, check how the output changes when these peripherals are disconnected/reconnected – what happens to the sound and the playback.
First of all, testing audio files should begin by ensuring which (if not all) files are recognized by the app. This is done by checking if the files you copied appear in the app’s playlist.
To simplify the process, name test tracks based on their specs, e.g., “44100-16-320.mp3”, meaning that the file has a 44100 Hz sample rate, a bit depth of 16bit, and a bit rate of 320 kbps.
The next step involves playing the files one by one for around 10-20 seconds each. In some cases, bugs can cause the files to stop after a few seconds.
If 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 appear using the seeking bar. However, it may not necessarily be a bug, as files that don’t have a constant bit rate can pose problems to the developers.
Files with special characters in their names, large files (2, 3, 5+ GB), or long audio files (2, 3, 5+ hours) should be able to run without any issues.
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 track should be tested on the device’s internal speakers, using a pair of headphones connected via AUX and Bluetooth speakers.
Focus on how clean the audio files are. Check for stuttering, distortions, artifacts (sounds that should not be there), inconsistent playback speed, etc. These tests presume that you, as a tester, are familiar with the test tracks 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 hard to differentiate 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, 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).
Note that some effects can clip the audio file, and too high a volume can distort it. These are not always bugs, so check the are adjustable settings; if not, that should certainly not happen to a clean, normalized audio file.
Also, see what happens if another audio app starts while the song is playing or while external sounds are playing (a notification sound, a message, or an incoming call).
There are many tests that can be run; our suggestions only cover the most basic 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.
Don’t hesitate to contact us for more information: