Solved: Mazda (JCI) Infotainment crashes when playing OGG Vorbis files

The Fix (Tl;dr): The Mazda Connect (a.k.a. “JCI infotainment” or Johnson Controls Infotainment, etc.) firmware available as of 1/2016 has a problem with long tags in Ogg Vorbis files, specifically the tags used for album/cover art. Vorbis files containing cover art will likely cause the radio to freeze and then reboot. To fix this, you need to FULLY strip any such long tags, including any padding left behind after their removal (in some software “removing” the tags only zeroes them out, leaving blank space in the file, i.e. the filesize does not change). This is specific to Ogg files, it seems to have no trouble with cover art in mp3 ID3 tags.

To fix this, I’m using the CleanTags script with a minor tweak to force it to fully rewrite the files (no padding) rather than simply zero out the data. There are probably off-the-shelf GUI executables that can fully strip tags too, but I don’t know any off the top of my head, and they probably don’t advertise this as a feature since there’s really no need to do it unless working around an obscure bug in a specific in-dash music player. If you know any, please reply in the comments!

To use the cleantags script, you need to have Python (2.x?) and mutagen installed on your computer. After downloading a copy of cleantags, find the line containing:

and replace it with: x:0)

Whitespace matters in Python, so be sure not to mess with the indentation of the line. Then, run the script as usual (see documentation) and it should fully strip more obscure tags including the problematic cover art, avoiding the bug in the infotainment system’s player.

Up until recently, I’d been kicking it oldschool with my music collection: artist and song name embedded right in the filename; duplicating this info in internal metadata was for sissies (or people with entirely too much time on their hands). After finally retiring my old car for a modern new one with all the bells and whistles (Antilock brakes! Traction control! It plays mp3s?!), I discovered the stereo*, for all the sweet things it can do, will simply display “Unknown Artist/Unknown Title/Unknown Album” for any song files not formally tagged with this info, rather than fail over to displaying the filename (heck, even my homebrew old one did that). That was annoying, so I finally caved on the metadata issue. Well, really, my issue was not giving enough of a crap to sit there like a monkey retyping the filename info across a zillion files into a tagging tool. Luckily, we live in the future! and the drudgery of tagging mp3s can now be crowdsourced and automated.

The tool I’m using for this is MusicBrainz Picard. Basically, think Shazam for ID3 tags. It scans the files to generate a fingerprint based on acoustic content and length/etc., pulls the nearest-matching results from a crowdsourced database and Bob’s your uncle. It even grabs… cover art! And puts it right in your file! And then your music player shows it while playing the song! There’s a STANDARD for this! Like I said, the future. Up until that moment, I didn’t even know you could do that. And here is where the problems began.

Some time passed, and files from my now-tagged music collection eventually propagated to the USB key plugged into the dash**. Some more time passed. All of the sudden, after a couple months, the car stereo started to crash sporadically when playing songs off the USB key. Due to the whole not-showing-any-filenames-ever thing, it took a while to figure out it was crashing every time it tried to play a .OGG file. OGG files comprise a fairly small minority of my music collection***, which is why the problem was so sporadic and didn’t manifest right away.

Tracking down the problem actually took a bit of fiddling, since the tagging was no longer fresh in my mind as a first-guess trouble source. My first guess was that since all the files showing the problem were fairly old, and a freshly-generated Ogg file with the current encoder played back fine, bugs in the way-back-when encoder or obsolete version of the format were the most likely culprits. This eventually led me down a bit of a rabbit hole of Ogg diagnostic tools, so the below might be useful if you’re having other Ogg-related playback troubles on other players.

What I’m calling an Ogg music file is really a “Vorbis” bitstream, i.e. the actual compressed audio stuff generated by the Vorbis codec, packaged into a file using the “Ogg” container format, so separate problems can occur at either level. If this were a buffet, the Vorbis bitstreams and tags, etc. are different foods and the Ogg container is one of those silly divided cafeteria trays.

The Oggz tools are probably the most approachable way to check for problems in the container itself. These are command-line tools, but available as ready-to-rock executables for major Linux platforms and even Windows. The oggz-validate tool will warn you of common errors or inconsistencies in the file, and other tools in the package will help you dig further. Despite its intended usage for merging multiple files, oggz-merge can be used with a single file to correct some errors like out-of-order timestamps(?) and missing end-of-stream indicators. Note though, warnings from oggz-validate do not necessarily mean your player will choke on the file (for example, missing EOS page is very common and should be fairly harmless as most players should know to stop playing when the file itself ends.)

Assuming the container checks out, the problem could be in the codec-specific data stored in it. Ogg is really a content-agnostic container format and can hypothetically contain any sort of audio/video/etc. streams, but Vorbis audio is probably the most common by far. In this case, your debugging options may be more limited. The only tool I found for validating Vorbis bitstreams is a C program called ‘vorbose’, available only as naked source code in a SVN repo. To use this, you also need to install ‘libogg2’ from the same repository, which is different from the ‘libogg’ available in any Linux package manager and will require you fetch the source and compile that yourself too. Luckily, there are no further dependencies. Once you provide the platform-specific magic incantations to make your computer cough forth a locally-sourced, artisanal, sustainably raised executable, you can use the -w option to “report anything fishy in the stream” (don’t ask me how comprehensive this is), or even -v to learn more than you ever wanted to about the file.

* otherwise known as “infotainment system”, since it does all sorts of other stuff, like service reminders and even GPS navigation as an (horribly overpriced in the era of cheap Garmins and Google Maps) option. As such, this thing is somewhat intricately tied into the bowels of the vehicle, so it’s generally easier to work with its problems since replacing it is not as simple as the headunit swaps of yore.

** next to the Raspberry Pi, which is, in a first for Raspberry Pi-kind, not being used as a media player (or retro console emulator).

*** Of the many things I experimented with in college, Ogg Vorbis was one of them. It’s a great format, but fairly unheard-of at the time, so when portable music players started to come out (e.g. Nomad), it was guaranteed they wouldn’t be able to play them. This was also a time in computing history where you’d start a single song encoding into mp3, go to class, and hope it was done when you got back. Playing an mp3 (~50% CPU time on my “newish” computer at the time) meant pausing it periodically so mIRC chats could catch back up to realtime. Needless to say, re-ripping one’s CD collection (remember those?) into an obscure format with even modestly slower encode/decode speeds was a tough sell.

Leave a Reply