JVC car stereo 2017 model does not read MP3TAG wav files but 2014 model does


#1

I upgraded from JVC KW-R910BT © 2014 to JVC KW-R930BTS © 2017 car stereo. I immediately noticed that .wav files are no longer being read (.mp3 tags are still fine.)

I experimented with a program that consistently is able to make readable .wav tag files AudioShell.

It made a .wav file that is readable even on the 2017 model.
I am attaching both AudioShell and MP3TAG made .wav files in hopes that you can compare them and find out what the difference is:

wavSamples.zip (2.4 MB)

Thank you for your time.


#2

A look at the read tags shows (ID3v2.3 RIFF) for one file and (RIFF ID3v2.3) for the other (handled by MP3tag).


#3

Okay. To experiment with this, what is the quickest way to simply switch multiple files and folders from RIFF to ID, without changing anything else, just to see if this will (for whatever reason) be then read by new models of car receivers?


#4

Upon further experimentation, this appears to be the issue:
When I add one character to the title inside the AudioShell program and Save, it converts the tag from
ID3v2.3 (RIFF ID3v2.3)
to
ID3v2.3 (ID3v2.3 RIFF)

Average users don't really care "why" but since this appears to be the solution for wav tags to be read vs. not read, is there a setting in MP3TAG than can just convert all tags from
ID3v2.3 (RIFF ID3v2.3)
to
ID3v2.3 (ID3v2.3 RIFF)

If there is not, can we have one please, what would it take?


#5

Sorry to bother you guys but does anyone of you know is there a program that can mass convert tags of hundred of wav files to ID3v2.3 (ID3v2.3 RIFF) so I can further experiment with this?


#6

Have you asked JVC why they changed the tag reading?

Anyway: I read the product description and apparently they are very proud to replay flac files - so you could convert the wav (lossless) to flac (also lossless) and see if the tags are present...

I do not know which order is correct but I read in a fairly old thread that riff/id3 is ok but having id3 first is not ... no warranty here, though.


#7

Thank you for posting.
You raise really good questions and I am interested in discussing them with people here who know how tags work. But before doing that, let me just say, IF this is a situation where a major brand reads tags only if they are XYZ then it doesn't really matter what XYZ is or even why.

What matters is can we make Mp3tag do XYZ? That's the only thing that matters, because as a user and not a creator of Mp3tag, the only thing I care about is that the Tags are read. If they can only be read if they are XYZ, then how do I make them be XYZ?

So I am primarily interested in finding out if converting wave file tags on a mass scale to ID3v2.3 (ID3v2.3 RIFF) will resolve the problem? I don't know what ID3v2.3 (ID3v2.3 RIFF) is! It doesn't really matter but YES, whoever knows about tags here, I would be very much interested to know what that is, and why Mp3tag can't do it?

But to address your questions. JVC is a huge major manufacturer of car radios and JVC Technical Support number is 1 800 252 5722 but I would imagine that it would be next to impossible to get through to an engineer in charge of tag reading and ask why they made this change.
It would be much easier to make Mp3tag do this because this other program Audioshell, Mp3tag's competition, is already doing and Mp3tag should too.

Specifically addressing your point, this is not about the DEFAULT way.
Whatever default is is irrelevant, Mp3tag can continue using whatever it is using but maybe there should be an option (just an option) to do ID3v2.3 (ID3v2.3 RIFF) and that way, rather than making JVC switch, the big picture is what if some other major manufacturer does it in the future?

There is no getting around the necessity for this to be an option in Mp3tag.

And in the end this entire topic is about a HUGE assumption that ID3v2.3 (ID3v2.3 RIFF) is the reason why 2018 JVC models are reading tags created by Audioshell but are NOT reading tags created by Mp3tag.
I hope that the reason is ID3v2.3 (ID3v2.3 RIFF) because IF it is - then it can be addressed: Just make Mp3tag do it too in options...


#8

WAV files can have both ID3 chunks and RIFF INFO chunks for storing metadata and it seems that the order might be causing the hick-up there.

However, I've also noticed that the track number has a leading zero in the file that doesn't show on your player. Can you remove the leading zero and try again?


#9

Hi Florian. All wave files I have are originally tagged by Mp3tag (of course).
Example files I uploaded here had to be shortened and since I don't know if that is responsible for the leading zero, may I ask you: what do I do to the original large wave files to see if there are any leading zeroes and how do I remove a leading zero?

There is nothing I tried in Mp3tag that can make wave files be read on new 2018 JVC players. If I change the name inside Audio shell - they can be read. I am speculating why, but with your help I can test and figure it out.


#10

I'm referring to the leading 0 in the track number field. Can you remove that one, resave and try again?


#11

Thank you Florian. Please use these two new Samples to see if anything else is there since neither has leading zeroes and one works the other one does not:

Samples2.zip (2.4 MB)


#12

OK, another idea: are you using the latest firmware version (v114) with that device? Refer to the "CD Receiver Firmware Update Guide" for checking the firmware version.

http://www.jvc.net/cs/car/firmware/2018/kdrd99bts/


#13

Florian, thank you.
I have made sure that firmware was updated to the latest version immediately after I upgraded to this 2018 model after taking out the model from JVC's previous generation.

It is certainly possible that there is a massive bug affecting JVC 2018 products. With just a little bit or your help, I am ready to take the long way and pursue this with higher levels of JVC technical support.

However, I do need your help to get a little bit of your knowledge on this topic.
Namely the two new example files.
One of them made by AudioShell does work. When we look at the new differences in Sample2 I just uploaded, leading zero is no longer a suspect.
The only thing visible appears to be that Audioshell is ID3v2.3 (ID3v2.3 RIFF)
Mp3tag is ID3v2.3 (RIFF ID3v2.3)

Can you please post if that means anything. Can you please also confirm that it is the only difference between the two Sample#2 files that you can see?


#14

Since the example files do not share the identical metadata, it's hard to tell. So I've made myself some example files using the same base file and the same metadata but in different arrangements.

Can you try the attached files and report your findings? I can then most likely give you a complete description of what would be needed to be changed for the firmware to read those files.

c627627.zip (1.2 MB)


#15

Just a quick reminder about the importance of keeping the filenames 7 or 8 characters so as to distinguish if the display is showing a File Name or an actual TAG. Long file names, especially if the sound file is short, make it impossible to distinguish between the two.

So I renamed file names to ID3.wav. ID3INFO.wav and INFO-ID3.wav.
Neither of the test files shows the name tag or any other tags except for file INFO-ID3.wav which shows the Album name TEST:

I took a picture of that and I will very much like to submit a case to JVC and then try to escalate it, but I thought I would wait to see if any further tests can be done and if you could help me word the case for them to investigate. My only point of concern is that somehow that other program is able to create a tag that can be read and it would be interesting to see how or why. To pinpoint the procedure:

I opened all three test files in Audio shell. I ONLY changed the TITLE TAG and Saved. No success on any of the three files.

Then: I opened all three test files in Audio shell. I removed everything except for the TITLE Tag.
So with ONLY the TITLE TAG remaining in AudioShell, only one of the files: the one originally named Tone-250Hz-ID3.wav finally displayed the TITLE TAG, here is the picture of how it did it (The changed name of the Title Tag was 1ID3 and it did display:

Here is the file itself:
ID3.zip (419.1 KB)


#16

Unfortunately, I currently cannot explain the results of your experiments — it's still too mysterious to me. While thinking about the issue over the day I had another idea.

Can you try again with the attached files? Please don't process them with any other program, as it would influence the outcome of the experiment.

If anything is displayed for those files, I'm interested in the title that is displayed.

c627627_2.zip (1.2 MB)


#17

Test results: Only one single entry is visible: on file INFO-ID3.wav for album name which is TEST. Nothing shows up on other two files and other information is not available for INFO-ID3.wav either. I am ready to contact JVC engineers and push this if you can help me formulate what it is I am asking them to do.

I managed to get a file where both TITLE tag and Artist Name are visible and I am attaching it here:

11 Aces High.zip (1.6 MB)

When viewed in Mp3tag this fully working wave file tag has one thing in common with your INFO-ID3.wav:
They are both listed as RIFF ID3v2.3
whereas all non-working tags are listed as ID3v2.3 RIFF

Does that mean anything whatsoever?


#18

OK, then it's probably best if you contact JVC support. You can point them to the test files I've provided and ask why they're not read and if they can fix it. They can also contact me via email in case they need further technical information.

The difference between "RIFF ID3v2.3" and "ID3v2.3 RIFF" is that in

  • "RIFF ID3v2.3", the RIFF INFO chunk is located before the 'ID3 ' chunk, and in
  • "ID3v2.3 RIFF", the 'ID3 ' chunk is located before the RIFF INFO chunk.

However, the current observations

are inconsistent with what you've described above when talking about files that are displayed correctly:

A solid RIFF parser should read the chunks independent of the order and the previous model apparently had no problems with reading those files.


#19

Thank you for pointing that out.
Rather than look into this further, let's try to get JVC engineers involved.
I was the owner of three consecutive JVC generations, and the two previous models did not have a problem with tags.
JVC just told me that 2nd tier technical support will get back to me in 24-48 hours. It may be some time after that before I can get all the way up to engineers but I will use your most recent samples to simply ask them why they cannot be read, as that will address the problem straight away.

Thank you for your time and for making the best tag making program on the internet.


#20

JVC is now running tests on your second set of sample files...