Recently Eyal Mozes hired me to determine why the sound system in his new Honda Civic wouldn’t play some MP3 files. This was a chance to do some interesting investigative work, and I’ve found what I think is a previously unidentified product defect.
He sent me twenty MP3 files, ten of which would play on his system and ten of which wouldn’t. First I ran some preliminary tests, establishing that iTunes, QuickTime Player, Audacity, and even my older Honda stereo had no trouble with the files. Then I ran Exiftool on them and looked at the output to see what the difference was.
The first thing I looked for was variable bitrate encoding, which is the most common cause of failure to play MP3 files. None of them used a variable bitrate. Looking more closely, I saw that all the files had both ID3 V1 and V2 metadata. This is legitimate. In the files he’d indicated as non-playable, though, the length of the ID3 V2 segment was zero. This was true in all the non-playable files, while all the playable ones had ID3 V2 with some data fields. I verified with a hex dump that the start of the files was a ten-byte empty ID3 V2.3 segment.
I continued looking for any other systematic differences, but that was the only one I found. It’s highly likely that the MP3 software in Eyal’s car — and, therefore, in many Hondas and maybe even other makes — has a bug that makes a file fail to play if there’s a zero-length ID3 V2 segment. (Update: Just to be clear, this is a legitimate if unusual case, not a violation of the format.)
Eyal had gone to arbitration to get his vehicle returned under the warranty; Honda’s response was unimpressive. Initially, he told me, Honda claimed that the non-playing files were under DRM. This is nonsense; there’s no such thing as DRM on MP3 files. They withdrew this claim but then asserted that “compatibility issues” related to encoding were the problem, without giving any specifics. The ID3 header in an MP3 file is unrelated to the encoding of the file, and I didn’t see any systematic differences in encoding parameters between the playable and non-playable files. Honda claimed to be unable to tell how the files were encoded. They may not have been able to tell what software was used, but the only “how” that’s relevant is the encoding parameters.
This problem won’t make your brakes fail or your wheels fall off, but Honda should still treat it as a product defect, come up with a fix, and offer it to customers for free. If they can upgrade the firmware, that’s great; if not, they’ll have to issue replacement units. The bug sounds like one that’s easy to fix once the programmers are aware of it. The testing just wasn’t thorough enough to catch this case.
If anyone wants to hire me for more file format forensic work, let me know. This was fun to investigate.
Thanks for the detective work!
Honda’s dishonesty about this defect is quite evident. Other than the nonsense claims you’ve related here, they also stated in their response letter that the system generates an error message when it tries to play the files; this is a lie, since in fact there is no error message. When at the hearing I suggested that the arbitrator come with me to the cat to see for himself that there is no error message, the Honda representative withdrew his claim and instead claimed that it is legitimate in some cases for the system to fail to play a file with unsupported format without any error message. When I pointed out that the Owner’s Manual clearly states that the system will display an error message in such cases, the Honda representative’s response was: “You can’t expect the Owner’s Manual to be accurate; it’s not a technical support manual”.
My experience indicates that, other than lying, Honda’s central strategy in dealing with this defect is to instruct their Customer Service people to be as rude and abusive as possible to anyone who reports problems with the audio system, in the hope that the unpleasantness will make the customer give up.
Of course, having proven the bug doesn’t guarantee I can get Honda to actually do something about it. I’m in the process of looking for a lawyer now.
It would likely help your case if others have reported similar problems. I’ve found one other report on a website. That person thought the problem was variable bit rate, but it’s also possible that when she transcoded the file she eliminated a zero-length ID3. There’s a contact option in the menu if you want to try asking her.
The report there says the system did display an error message when failing to play the files; that makes it clear it’s not the same problem. With the files I sent you, the system just shows the file as playing for a few seconds, with no sound and no error message, and then skips to the next file.
As I noted, the evidence indicates that Honda’s strategy so far has been a combination of lying and deliberately abusive behavior towards those who report problems with the audio system, hoping the unpleasantness will make them give up. It’s quite possible the strategy has worked on everyone else who’s reported such problems.