I've been using MP3Tag susccessfully for several years to properly tag audiobook book files so they will play, continuously, in order on my MP3 device (iphone, ipod, ipad, etc.).
However, yesterday I was attempting to tag several Harry Potter books from my local library and ran into the same issue on all of them.
I have posted 2 screen captures to save a lengthy, convoluted explanation!
The first is the tag I have been using that has always worked, until yesterday.
The second is a capture of the actual error message I get when trying to apply the tag string.
The files appear to be ripping from the audiobooks without any issue and I have not changed or altered the software I use to rip ( Audiograbber Pro 1.83).
Any input, observations or comments would be greatly appreciated to get me back on track.
Thanks everyone and please stay safe!!
Looks to me like the tags for the audio book ar not filled. You only get the string constants from the format string plus the "nothings" that have been converted to 2-digit numbers.
So fill in the tags.
Thank you for your input, I appreciate you!
After posting, I took a closer look and realized, for some reason, the ripping software was not capturing the book data.
I went in and manually entered all of the tags and still get "duplicate" entry errors. I have attached a screen shot of the error and the info screen with the information. So, it does not appear to be an issue with the lack of information but something in the program seeing the file as a duplicate of some kind.
Again, any assistance with this is greatly appreciated!
As you can obviously see you really create always the same filename.
The reason seems to be that the track number does not vary and does not seem to be set - the 2-digit track number reference in $num(%track%,2) still results in 00.
If the data in all the other fields does not vary, naturally, the filename will also be the same if generated from this data - which the file system does not allow.
You need to fill the field TRACK with a unique number per CD.
Thank you, I understand that part.
I guess my question is that, in the past, that track number was automatically populated from the CD information captured during the ripping process, why is it no longer "seeing" that information?
I checked the settings in the ripping software (Audiograbber 1.83) and it is set to capture the track number.
Now, it appears I have to manually enter the track number for CD in order for this error not to occur.
Any idea why MP3tag is not seeing the track data when has for the past several years?
Also, is there a CD ripping software you would recommend over Audiograbber?
How should I answer that in a decent way? If it has worked before, you would have to ask yourself what has changed in the meantime.
Also, it could be that simply no data got transferred by the grabber - AFAIK freedb has been stopped.
You could check whether you have APE tags (tags not fields) in your files. You would then have to find out why they are there (i.e. which program in your workflow has added them) and eventually get rid of the APE tags.
Thank you again for you insight, I greatly appreciate it.
I am aware that freedb ceased operation earlier this year although I doubt that has anything to do with this since I never used that service for audiobooks as there was never any data posted to the database.
I'll investigate further.
Thank you again
Did you know that MP3tag has a track numbering assistant.
Perhaps that function helps you to get track numbers.
No, I was not aware of that!
I never needed it before but I suppose I will learn something new today!!