Difference between Discogs' timestamp and actual file duration of track

Sure, hon!
My friend warned me that

would be the answer that I'd get, and... there it is. You wrote it yourself.

By the way, you point to a websource scripts page, not to the source code of the software, which, as you would know already because you seem to know that much about writing code, is what my friend needs to implement that feature. Do you have them, by any chance? Because that's what my friend said: "Tell him to provide the source code of the software and I'll do it myself, yeah, and no, my face won't turn pale at all".

Not a single time I said anything that could mean I'm demanding, in my first message explaining about the subject I wrote I am suggesting.
And anyway, if it is something that if it is something up to the developer to decide wether he invests his valuable time on writing the code for a certain function or not, why all of you are speaking as if you were the ones who write the code and keep the project alive?

If the program is a personal project, keep it for yourself, but if you share it to be used by the community, the least to expect is that feedback from users is to be taken in consideration, not only for the bugs they could find while using it, but, also, for the new features that they could suggest and that the developer didn't think of.

Greetings to you all!

No.
Mp3tag is not a an open source project.
There is no Github repository or a similar public place where you can read and modify the source code.
The linked Websource Scripts - where you would compare the track durations - would be the only way for us to implement such a feature.

The whole discussion seems to get a little circular now and in part diverts from the OT. I've read the original request and made a note regarding the suggestion β€” it's an interesting idea, but it's not very likely to be added in the near future, though.

As for the comment by @LyricsLover regarding the Web Sources Scripts: I don't think it's possible to implement it on this layer of abstraction, it would have to be done in Mp3tag's core. It was maybe (?) also only a meant as a reaction to the statement regarding "in five minutes it would be ready", which seems to be amazingly little β€” even for a small feature. Your friend must be one of the 10x developers (which is great!) :smiley:

Absolutely! Many of Mp3tag features are results of suggestions from the community, either directly implemented or fruits of a collaborative process where we started to think and create ideas together.

But I don't pick up every idea and some take a long time ripening: Mp3tag as it is now is a result of many, many yeses and thousands of noes.

Yeah, I perfectly know that, which is the reason why I was suggesting this functionality, because it is something that has to be done within the inner code of the software. Scripts are useless for that, and my friend confirmed it to me when he had a look at it.

Not that I was expecting to see that functionality in the near future, but I'm thankful that my idea has reached to where it can be considered.

I have several ideas to improve your software, things that would make the user experience easier and faster. Don't know about others, but in my case, I have thousands of albums. I've tagged with your software 3176 so far, but still have around 8500 more waiting to be tagged and many times I'm using it I'm thinking: if this software had this functionality would make work easier, or that other one, or... or... But I often think: no, leave it... forget about it because nobody is going to pay attention to your suggestions even if they would be actually good and helpful. But yeah, I may as well open a thread with a list of things I think would make the software better and more complete. Of corse, I know, as well, there are functions some people would not use, while others would.

I tried other tagging softwares but either they were useless, too messy to use or unattractive. I remember one which was a true nightmare. It promised to be automatic tagging recognising the tracks itself pairing with info from Internet and in the end it turned out to be a bad egg. It made a mess of the few albums I put into it to be tagged, just to give it a chance. So I stick to your software because I think it is the one that fits my needings.

And finally, having nothing to do with the original subject of this thread:

I'm afraid he is, but he is 55 y.o. and after working on developing since he was 21 and dealing with computers since Spectrum days (here, in Spain, since mid-1980s) he's fed up of typing code so he usually gives me a hand and guidance, but little else. He has enough to do with his job. He just wants to retire now, and after going through cancer I don't want to bother him too much. But yes, he has a privileged mind, he's a crack: He never had to study, he corrected professors at university many times, even if he was sick he was able to give instructions over the phone to other colleagues at work to correct software errors.

Anyway, as I told you before in another thread: thank you humbly, again, for your software.

I've noticed several CBR mp3 files display a time in windows 10 file explorer that is longer than the actual duration of the file. Using Audacity to resave the file corrects the problem - UNTIL I add an album cover. I noted the time duration of the file after exporting from Audacity and it was correct. When I added an album cover with Mp3tag, the file time duration increased by 18 seconds for this particular file. VLC will play the file correctly without any added silence at the end, but the file duration does display in VLC as the longer time length.

Probably Windows think that the image is audio.

My guess is that windows sees the slightly larger file size with the embedded image and to display the time length it solely uses the file size and bitrate in the calculation.

Check the files - see these hints: