I’m new to using any sort of metadata editor/lookup like Picard so my apologies if my lingo is not correct.
I have been using Picard to update/add metadata to a music collection and I’ve run into a snag I cannot figure out.
For a half dozen album collections I’m getting a strange behavior that I’ll do my best to describe.
Example: Album is “In Search Of The Lost Chord” by The Moody Blues. When I view the tracks in Windows 10 File Explorer the first track is called “Departure.mp3” and the reported Track Length in the File Properties is 00:00:44, which is correct. When I load that file into Picard the Track Length is reported as 2:26. Another Track in the album (Ride My See-Saw) in Picard is reported with a Track Length of 0:44 when it should have a Track Length of 3:39. And so on…
So all of the file names and track lengths are scrambled up when I load the Tracks into Picard.
I’ve stripped Tags from the files using Mp3tag but the issue remains.
I saw that in each of the offending albums folders in File Explorer there was an iTunes Playlist file which I’ve deleted because it is garbage I don’t need/want, and I’m wondering if there’s some kind of digital ‘signature’ or something that was added to these files by iTunes.
I’ve tried renaming the mp3 files to no avail.
I hope I’m explaining this clearly enough.
Anyone have any ideas of what is going on with these mp3 files and their ‘misinterpretation’ by Picard?
Can we get a screen shot of Picard with the tracks loaded? This sounds a little odd.
Picard and MP3Tag will just read file lengths from the file. So would Win 10.
When you have a file loaded, in picard, highlight it and at the very bottom on the status bar is the filename. Is this the file you think it is?
Without more detail it is difficult to be certain, but I suspect what is happening is that the 00:00:44 is the actual track length, whilst the new metadata of 00:02:26 is the length of the recording in the MusicBrainz database that it gets matched to.
It is quite common to get a discrepancy of a few seconds - recordings are reused and sometimes slowed or speeded slightly, or the inter-track gap is included sometimes and not included other times, or the track is faded more quickly on one release than it is on another etc.
But when it is more than a minute different, that is suggesting to me that you have your music file matched to the wrong release/track/recording in MusicBrainz.
So here are some screenshots.
One is of Picard showing the requested info.
The other is File Explorer showing what it reports.
The last is from MusicBrainz showing the correct Track length of 0:44 seconds.
Did you rip the first track “Departure” by yourself?
Could it be that during the ripping or converting process something got wrong with your track?
If you play this song - for example with VLC - does it play 44 seconds or 2 minutes and 26 seconds?
This looks a bit like the files got tagged with the wrong metadata. If you listen to it, is the file for Departure actually playing that song?
For MP3 the audio length could be stored as a tag TLEN (unused by Picard), stored in a special header or to be calculated from the bitrate. Getting the correct length can be surprisingly tricky, especially for files with variable bitrate (VBR). Sometimes the information in the headers is wrong and leads to wrong length calculation. Or there is no information for the length at all.
As a last resort audio length can be guessed from file size and reported bitrate. If the file contains extra data at the end, e.g. an APE tag block tucked to the end of the file, this can increase the file size and hence increase the audio length estimate. You could try saving your files with the option “Remove APEv2 tags from MP3 files” and see if the length is reported correctly afterwards. Of course this will delete any APEv2 tags present in the file. If you want to avoid this and check before you could load the files into MP3Tag, which can show you the content of the APE tags explicitly.
It could also be a bug in the mutagen library, which Picard uses to read/write metadata in audio files.