I’ve recently started using version 1.4.2 of Picard, and am encountering an issue that I don’t think existed in 1.3.2.
If I drag a bunch of saved flac files (comprising an album) from the file-browser panel into the main panel, the album is looked up on MB, and the data from there downloaded and compared with the metadata stored in the file. Any mismatch is highlighted in the lower panel, and if the data are not identical the disc icon acquires a little dot at top right to show this. Clicking ‘Save’ updates the local file with the MB data and the little dot disappears.
So far so good. But the problem is that the track times read from the local files are read from the audio file itself and cannot be changed locally (and nor should they be). If the data on MB differ from these (for example, because they were entered as printed in the CD booklet), the discrepancy is flagged, the little dot shows up, and clicking ‘Save’ makes the little dot go away. But it doesn’t fix the discrepancy. So if the process is repeated, the little dot appears again.
I am not sure this should be marked as a discrepancy at all. Or if it is, it should be marked in a different way to indicate that it is not something that can be corrected by clicking ‘Save’, but only by editing the data on MB.
Before raising this as a bug I thought I’d raise the issue here in case I’m missing something obvious. I couldn’t find any relevant control in ‘Options’.
OK, I’ll bite. I’ve seen it as well, and you probably should update the database. :
On the other hand, which one is correct? I know I have a couple tracks that do not indicate the proper time. I had a problem with file corruption, and I ended up having to trim some frames (term?). The file sounds fine, except it starts or ends a bit more abruptly. (The ones still in my library are only there because the original CD was lost to disc-rot.) The point is, the files report as being a couple of seconds shorter than they should be. I probably shouldn’t update the database with that info.
Back when I still played CD’s, I seem to remember seeing the player indicating “0 secs” left for a bit while I still heard music. I know it happened with WinAmp. Not often, but it happened. I didn’t compare at the time, but there are now three potentially different times reported; CD, Player, and file. Which one is correct?
The point is; I always assume that the time is not exact, and that a couple of seconds difference can still be a perfect match. There should be a way to indicate that minor differences in time are always acceptable.
It’s also possible that I’m totally wrong, and I accept that.
I ain’t gonna pretend to be an expert either. So here are thoughts from my head.
Firstly - @Pha3drus your example tracks that have been edited and trimmed sound like example that shouldn’t be used. Bit like when AcousticID numbers are made of tracks like that, I assume that they shouldn’t really enter the system. I know this confuses me when I have a few rotten disks with damage in tracks - but I don’t know how to stop them being uploaded with other good AcoutsticIDs.
I think the correct place to find the actual correct lengths are in the TOC that gets uploaded by Picard with the disk ID. I believe that this is a verifiable set of lengths taken direct from the CD’s own contents table. That should be the real lengths.
With the CD player “staying on 0 seconds” for a while that will just be the player putting in a gap between tracks. Stick on Dark Side Of The Moon and I guess there won’t be those gaps.
There should be somewhere in the Help Pages that defines “track length”. Maybe one of us should read the manual - lolz. So I’ll give that a go…
I know this is a stage I have hit the problem before. I’ll upload a CD TOC from one of my CDs, and find it is a new release. I attempt to add the details for that new release. Each track gets the correct times setup from the CD TOC. But then I have to line up the new tracks to recordings already on the database. And this is where I find the odd error creeps in - the nearest match is 2 seconds longer, so I’ll link to that one and move on.
This especially becomes a problem on compilation disks.
@IvanDobsky It’s been so long since I’ve actually listened to a CD instead the files.
I think two things give us everything we need to know;
From your first link " If more than one exists, it calculates the average length of all the TOCs for a given CD and picks the closest one to the average."
From your comment on the second link;
It seems like duration is no longer considered critical. If that’s the case, we should be able to permanently accept our local differences.
Thanks for the replies. The reason this bugs me is that I like to periodically update all my saved files with metadata from MB, and I take the little dot (which on closer inspection I see is a star) as an indication that something has changed on MB. I don’t want to replace thousands of files with identical copies just because the durations on MB happen to be out by a few seconds. But nor do I want to manually inspect each starred album to see if there are any differences apart from this. I want the star to tell me ‘something on MB has changed since you last saved this’.
I’d be happy with an option in Picard that tells it to ignore differences in track times.
I agree. I can’t think of a specific example right now, but I imagine that there are other fields that people might want to exclude from that notification as well.
: