clough5290!

Thank you for this list! I think it could be useful for everyone who experiences this issue.
I have checked almost the same things and made these steps before changing the LAME format. Yes, you are right, I could play these mp3s in any other car. It looks like this type of VOLVO can't manage this LAME format. Of course it's a bit annoying but... Hope the next generations will be able to manage this.
I think VOLVO - and other marks as well - will always deny there would be any problem, because of marketing reasons.

 

I recently bought a V40 XC and it wouldn't play MP3 files I bought off amazon that I'd put on a USB stick. CDs that I'd ripped to MP3 worked fine however in my V40. After trying BluMeUSB and various programs that removed Tag IDs, non of which helped me, I finally found a free application that did help called MediaMonkey: MediaMonkey » Free Media Jukebox, Music Manager, CD Ripper & Converter

All I did was to use mediamonkey to change the format of the problem MP3 files from MP3 to MP3 - sounds daft right but it worked - this must have removed something from the original (amazon) MP3 format that the V40 didn't like. I could do this by selecting all the affected files too and by ticking a check box to replace the old files with the new ones. So the effort was minimal in the end with Mediamonkey. Now all my MP3s work in my V40.

I hope this helps.

 

Another weird way of solving this issue. :-)
Thank you!

 

Like Mr Chips above, I recently bought a MY13 V40 and have had problems with it not being able to play some MP3s bought from Amazon that had been encoded from 2013-onwards.

Up until aroudn the start of 2013 Amazon used a compilation of LAME 3.97 to encode thier MP3 files, and I found all of these files I had worked on the V40's media player. I then tried some more recent Amazon files (an album released in 2014) and those files would not work, producing a 'TRACK UNREADABLE' error. After looking at the tags and headers in the files, the ID3V2 tags looked fine but the 'LAME Header' at the start of the encoded audio (see this page Mp3 Info Tag revision 1 Specifications ) that is used to hold information about the encoder, bitrate etc. was malformed. Specifically, the LAME extension that is added onto the original Xing Header used for VBR-encoded files (Amazon encodes all it's MP3s as VBR) is missing.

The the 'LAME 3.99r' string is visible in the ID3V1 tag area when loading these files in a hex editor, so the files had been encoded with a version of LAME 3.99, but one with an error in the code that writes the LAME VBR Header information.

I downloaded LAME 3.99.5 and used it to rip some CDs as VBR encoded MP3a and these files played fine on the V40. I checked the file contents and they had a correctly-formed LAME Header in them, just like the old Amazon files encoded with LAME 3.97

LAME is only distributed as source code due to legal issues with the owners of the MP3 encoder patents. It looks like Amazon took the source code for LAME 3.99 and have somehow managed (either accidentally or on purpose, possibly to track if their files are being shared illegally) to introduce an error into the code that writes the LAME Header to the file when they built their encoder.

As the Xing Header is still present, most MP3 players will still play the file, but may report incorrect track length and bitrate (and they will report the encoder as Xing, which fell out of use many years ago). My guess is that the only fault with Volvo's current media player software is that it is applying strict checks to the tags and headers in the files. As these Amazon MP3's are VBR-encoded but have a portion of the VBR header missing, it won't play them.

I have reported my findings to both Volvo UK and Amazon. I got a reply from Volvo Customer Support saying they have passed it onto the factory but I won't hear anything further. I have had a couple of replies from Amazon so far saying they are still looking into it. I don't hold out too much hope for anything to come of it though.

As Mr Chips has found, BLuMeUSB does not fix these files (it downgrades ID3V2 tag information to ID3V1 as FIAT's player doesn't seem to support ID3V2, but does not touch the LAME Header). However, after testing a few packages I have found a free tool called MP3Packer ( MP3packer - Hydrogenaudio Knowledgebase ) that does a crude repair on the header information that at least allows these files to be played. It is a command line tool, but it can be downloaded with a Windows frontend (called WinMP3Packer - the download link is at the bottom of the above page).

MP3Packer is normally used to remove padding and blank space from Constant Bit Rate MP3 files to reduce the file size (in effect it repacks them them look like VBR files, but still containing a CBR audio stream).

By default it will ignore VBR MP3 files, but, you can force it to process VBR files by changing the 'Input Types' tickbox from 'Auto' to 'All'. It will leave the existing audio stream data untouched, and if you use it on these Amazon MP3 files it also rewrites the broken VBR header, putting some of the missing extended LAME header information back in (though the codec ID still shows as Xing, rather than LAME 3.99),

I put my Amazon files with malformed headers though this tool and now they all work on the V40's media player, and without having to re-encode the audio data so no reduction in quality. I would appreciate it if anybody else who has more of these 'problem' Amazon files could give it a try.

 

Under linux, I re-encoded all Amazon mp3 files in a directory using the "lame" command, and afterwards I could play all of them in a 2013 XC60 which didn't work otherwise. I used the following linux command line to do this (re-encoded files have _V1 appended to their name):

Note there are two hyphens before the word "decode" above. This method probably results in some loss of audio quality, but I didn't notice over other road noise, and an improvement over the "unreadable track" error.

 

This thread has helped me resolve why some of my mp3's were not playing. I spotted on another forum that it can also be caused because "the system supports ID3 tags in UNICODE not ANSI. If the customer is using ID3 tags in ANSI this should not affect the playability of the mp3 file unless the mp3 file is encoded with some versions of the LAME mp3 encoder/codec.". I didn't try converting my tags but re-encoding the mp3 seems to be changing the encoding to a version that supports ANSI.

I expanded the above code to work on multiple directories:

for D in `find . -type d`; do for f in $D/*.mp3; do lame --decode "$f" - lame -V1 - "${f%.mp3}.mp3.mp3" ; done; done

and use the following to replace the original files within the new files.

find . -not -iname '*.mp3.mp3' -exec mv "{}.mp3" "{}" \;

Don't forget to then use fatsort or similar to get the tracks in the right order

 

Load those MP3’s into iTunes... convert them to M4A files... problem solved.

 

I presume these settings would work?