Hiya. Is there any way of having a column when getting results of a release to show the difference of seconds (even minutes, if so) between Discogs' data and the actual files we're tagging?
Not this release in particular, the differences are minimal, 1 sec. But I found other ones which had even minutes in difference, so the times were not actually matching.
I am suggesting this just because it would be easier to have as well a column telling the difference instead of having to go through all of the tracks and check track times left and right for all of the tracks... It's exhausting...
Discogs' timestamp should not be considered as an absolute reference.
The values are typed manually by the contributor who uses the duration indicated on the covers.
And often there are a lot of difference.
I see where the original poster is coming from, sometimes labels release different versions of the track in different markets (in one it can be the radio edit, and in another an extended edit). I have seen this occasionally, but not often.
Sometimes I have ripped a cd, where my version have one completely different track (in this case not even just a different edit or mix), but CDDB or something else auto-name it to what the names were in another markets version. In this case it could be really helpful.
Sure there could be many reasons, including human error when the initial record was created on Discogs.
But for many older recordings that were transferred to CD from analog recordings, the cover or label track times indicated may have been approximate and not aligned with the transfer to disc. Often the red book gap of 2s is not considered as well. Ripping software tends to add this 2s to the beginning of the following CD track.
Regardless, there is nothing for the actual file times that can be added, updated, or removed when it comes to the audio times in mp3tag.
I fail to see why the actual track times or the difference between the Discog (or any other data source) and user's files is relevant here and why development time should be spent on it.
Because as I said above, sometimes albums have one or two different tracks in different markets. And as you rightly point out, the audio file and length can’t be changed, so if there was an indication of times are off by a few minutes it is possible to catch it. And thus avoid that mp3tag tags incorrectly.
That's exactly what I am meaning, because sometimes you're taging an album with the info from another version of that album... And checking it by eye, left & right, left & right... once and again for every each track is just such an arduous journey.
And, by the way:
If there's a way to make tagging safer and easier at the same time... why not? Green numbers if your file being tagged's length is longer than Discogs' track timestamp. Red, if Discog's longer than your file...
Not that including a column in results window showing, in the middle of the two results, the difference between the discogs' release timestamps and actual files being tagged timestamps is such a development time consumming task.
It is as relevant as showing missing tracks, which, already, Mp3Tag does in window's results.
You don't have to convince me, it is up to @Florian to decide.
Perhaps instead of looking for gaps between existing data versus different releases, the track time instead could be added as a search filter to limit the displayed end results. If there is going to be additional development in this area, this would eliminate the need to visually look for discrepancies and narrow the results to those that more closely relate top your existing data. Not sure how feasible this is, but it would ideally present more accurate results.
I know I have to convince nobody, but I think that if there's anything to improve the user experience and make it easier, it should be taken in consideration.
Here is why not. The so-called Discogs "timestamp" is not intended as a defining element, like a fingerprint. It is simply a rough guide to playing time. All duration times are entered by Discogs database users (like ourselves) and they often have errors. Even CD liner notes can have errors or be misread on entry. Sometimes a Discogs poster simply used his watch to time the track.
Duration errors are permitted by Discogs rules. Errors of up to +/- 5 seconds are allowed without notation by the poster. And, even when a Discogs-entered length is much farther off, it will stay that way unless or until another user finds the error and corrects it.
So I think that comparing duration times between Mp3tag and Discogs is an unreliable way to detect different versions or issues.
You can review the many Discogs forum posts on duration issues here: Discogs Community Forum
I know timestamp is not always accurate, because releases' data is collected by user collaboration (I myself have contributed by adding albums to Discogs, or correcting, and I know what you're meaning). But, even having said that, it could be handy to the user to have some more control on tagging correctly. Pardon me for insisting, but I still think it would be a useful function.
By the way, I forgot to mention, as well, that it could also be handy to have a column with differences of time green/red (depending on the +/- difference). To be able to check if there's any disorder on the tracks, this would be useful...:
To find out if any tracks are out of order, i.e. have the name of another track but are in the wrong position:
For example, track 11 has the correct title, the one of track 11, but its duration is the one that corresponds to track 12. And track 12 has the correct title, but its duration is the one of track 11. So, obviously, there is an error in the sorting, because of the incorrect naming of the tracks.
Useful to you, I grant, because you are willing to live with the occasional errors from Discogs.
However, I cannot imagine that the developer will put his valuable time and energy into a duration display that is only accurate sometimes. That could mislead users and cause tagging errors, not what users expect from an Mp3tag feature.
Well... the program is for the users and not for the developer, and if that is a help for the user then it is useful and therefore the development time is not a waste.
First thing: yes, it is useful to me I would bet it is useful to many others... next thing: I think you are wrong, discogs is the most complete and comprehensive music information database out there, and third: the track duration information that discogs has is already retrieved to show in the results window, and the track duration information that is being tagged on the user's hard drive as well, so comparing two values with the same format, doesn't take a programmer that much time either.... Also, there is no need to do any calculations or retrieve any more information because it is already there, just to show the difference in some visual way. And I am not saying it myself, I have consulted with an engineer friend with more than 30 years of experience developing code in different languages and he has confirmed that in five minutes it would be ready.
And finally, it is exactly the opposite of what you are saying here
Precisely because all the information that can be made available is useful in avoiding errors, which, as you say, is something that users expect from an Mp3tag function. Remember: "information is power".
Just as side note:
Please ask your friend to do it if he really only needs 5 minutes.
It would be funny to see his face turn pale and his 5 minutes turn into 5 hours or even more.
And then you could point him to the Websource scripts and let him conjure up a real solution.
I never assume what any developer will consider to be useful or not. Especially with projects managed by a single developer like mp3tag. It is the product.
It is fair to propose a feature request. It is not reasonable to expect it to be integrated immediately, or possibly ever.
Wrong!
The program is a personal project that the developer uses, but chooses to share and/or sell.
He's the only one that decides what development time is valuable.
