Skip to main content


Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: How to test hardware MP3 players? (Read 2655 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How to test hardware MP3 players?

To Test MP3 Player decoder. Using recommended LAME 3.90.2

According to the information on

To test for Full Decode, VBR compatibility, 100hz bug.

Pick any 3 songs and encode them with these switches.

--alt-preset standard
--alt-preset extreme
--alt-preset insane

--freeformat -c 640 (just 1 song, see if it works; probably won't)

Then create a .wav file with lots of noise, then silence, then noise, then silence, then encode it with these switches.

-V1 -b
-V1 -b -F

Then create a .wav file with a 100Hz tone. Encode with --alt-preset insane.

You should now have 14 .mp3 files.

No ID3 tags. They are just test files.

Keep these files handy (burn to CD maybe) and use them to test your hardware MP3 player.

For the noise one I was thinking of creating a wav file with white noise (which should always encode at 320 in VBR mode) then sputter it with digital silence 10 times a second. Each second of an mp3 file is made up of 75 frames correct? So having digital silence every 10 frames should stress any decoder (software or hardware) more than enough since the variable bitrate would fluctuate between 0 to 320 very rapidly. Not needed here but would be interesting is to pan the noise left and right rapidly too. That gets the encoder alternating into joint and pure stereo modes.

Or instead of white noise, it could be 100hz tone.


How to test hardware MP3 players?

Reply #1

Yes. Your tests start from a good idea, and they'd probably expose some obvious flaws of a very bad mp3 decoder.. but except from that, I think they are too specific.

Example: I don't think you could *hear* anything wrong while listening to mp3 decoded noise. An incorrect decoder will decode noise incorrectly but unless you get very lucky, it will most certainly be similar-sounding noise.

I think that at least one of the following tests can't be avoided :
- real listening to real music
- digital comparison, which should match at +/- 1 bit with decoded output from LAME.


EDIT: a typo.


How to test hardware MP3 players?

Reply #2
Yes, quite very specific. My goal is to stress the hardware decoder to extremes. Many hardware decoders have difficulty dealing with VBR specifically. Most hardware can play CBR.

It's not that the noise will sound better or worse, its that if the player will play the file at all. Or if it skips or something.

When you've heard your file play on Foobar2k and compare it to how it plays on your portable, if there is no difference, then the decoder is probably okay.

I'm more into testing possible portable players. For the home hi-fi I would prefer a dedicated low-end cheap PC.

I'm looking to shop around for a cheap CD player, and I'll be bringing my disc with me to test various models before I actually purchase a unit.

My test CD will of course contain some real music. It makes me feel better though that a player can sustain an insane 320 kbps file for 3 minutes and can handle switching bitrates between 8 to 320.

I think I'll make an mp3 that has all the possible bitrates and switches among them on a frame by frame basis. Sort of like mp3 frame noise or something.

Overkill? hehehe. But if a player can play my wierd file, it's one of my choices in my shopping list. Quality of course is just as important.