# SUGGESTION: Count the lengths of files with accordance to reality

I made a simple experiment concerning the way Mp3tag adds lengths of files

I created a WAV file that was 44 Hz stereo 16-bit. And I made difference version of it on account of its lenght. And then multiplied it and loaded to Mp3tag. The results were

A] 1.000 seconds long file x 60 = 60 seconds in Mp3tag
B] 1.001 seconds long file x 60 = 60 seconds in Mp3tag
C] 1.499 seconds long file x 60 = 120 seconds in Mp3tag
D] 1.501 seconds long file x 60 = 120 seconds in Mp3tag

This might seem unimportant: but not when you are working with something like hundreds of 4-6 second files, that stacked together create a playlist. You get then result off by whole minutes. And this is plain wrong and misleading

That little experiment of mine was conducted in Mp3tag 2.95 on Windows 7 x64

Is this calculation correct?
Isn't that extra bit in

just a thousendth of a second? So you would need 1000 files to be 1 second off?!
So I wonder how

I would think that you would need 60,000 files for a deviation of 1 minute.
Listening to 60,000 files with a length of 6 seconds would then lead to 360,000 seconds of listening time or
6000 hours
or 250 days.
I think that after that time the deviation is negligible.

Are you sure of this calculation result?

I did some testing in v2.97. It seems that Mp3tag rounds off each file separately down to the nearest second before adding up the total time, which means that the total rounding error will increase with the number of files.

The error could be nearly 1 second for each file, which means that those 60.000 files could have an error of 60.000 seconds (> 16 hours) in theory.

As poster pointed out, those calculations are probably incorrect: 60x1,5=90 but Mp3tag showed 60 seconds when I tested, not 120. Still a rounding error though.

But personally I don't see the big problem. In my library most tracks are several minutes long, so a 1 second rounding error per track (worst case scenario) is negligible.

The problem seem to be very short files where naturally, the percentage of deviation is biggest in respect to the total length.
But do other programs do it better?
I took the value display from MP3tag, Foobar from the list, Foobar raw from the properties sheet and Windows Explorer.

Here a selection

File Mp3tag Foobar Foobar raw Explorer
1 00:02 00:02 0:02.250 (99 207 samples) 00:02
2 00:04 00:04 0:04.213 (185 795 samples) 00:04
3 00:03 00:03 0:02.913 (128 467 samples) 00:03
4 00:03 00:03 0:02.740 (120 844 samples) 00:02

In total the calculation is 116 thousandth of a second off the real value.
It looks as though MP3tag does not always round to the last whole second.
Actually, the MP3tag data matches fairly accurately that of the other 2 programs.
Except ... that the WE shows 1 second less for the last file.
So I am pretty sure that the more files you have, the closer the result will be to the actual time as it will level out on average.

So the statement

is not quite right as apparently other programs do exactly the same thing.

Strange - when I tested with a bunch of short files, Mp3tag always rounded off downwards.

Out of curiosity, I tried to match your files 3 & 4 - except mine got slightly longer.

Details in Foobar:

`0:02.915 (128 542 samples)`

`0:02.740 (120 851 samples)`

In spite of them being slightly longer than your 3-second files (3 & 4), Mp3tag nevertheless displayed them as being only 00:02.

I have no clue why your results differ from mine, but in reality it doesn't matter. Just odd.

Mine were all CBR, don't know if that matters

Possibly, I used wav files.

Edit / update:

I converted the files in my previous post to compare file formats. For the nearly 3-second files, FLAC and mp3 (cbr & vbr) formats were rounded off upwards but the wav files were rounded off downwards in Mp3tag. In Foobar though, all file formats were rounded off upwards.

A bit interesting, but nothing I would worry about.

My initials findings were correct. On purpose have I took time to create files that have an "excess" or are missing just a 1/1000 of a second

And yes I did double check that back then- and once again just now, repeating the whole process from scratch [with Sony Sound Forge 7.0 creating `44,100 Hz, 16 Bit, Stereo PCM wave file`]

But now the results were different. Until I hit the 2.000 mark, all I was getting with 60 files was 60 seconds [a second per file, even for a 1.999 long]. So was I wrong back then?

No. Because

and now I am using Windows 10 Enterprise x64 18362.239. [And it made no difference now if Mp3tag was in version 2.95, 2.96 or 2.97]

As I pointed out

And by `you` I mean of course `me`, as this is not some hypothetical scenario that I came up with, but an an actual task that I do 10-20 times a year. Sometimes I work with files that have even as little as ~2 seconds while building a playlist that is suppose to have 4, 5 or even 6 hours- and so I cannot be off more than one minute

Yes, also Winamp has problems with correctly displaying the total length. But that was one of the reasons that I started to use Mp3tag- to have the exact time given to me

And for the longest time I thought it worked as I imagined it would, with super precision. But as my test shown, I was wrong in that assumption

I am sorry but it is your statement that is wrong. This is basic logic [a case for a `sentence diagram` study, as Wikipedia hints me to translate it like that, that academical / grammatical process of which I am thinking of now]

The fact that a Software B and Software C also is not quite accurate does not turn proved inaccuracy of Software A to become something accurate

And to further state my ground: what if the not so long added ability to tag movie files turned out to by erroneous- in that the file that has 1:00:00 would be shown as having 1:00:04? Who of you would call it insignificant difference? And at what difference you would start calling it it a bug / issue that needed to be taken care off? At 1:00:00 being shown as 1:01:00?

But to be fair, this seems to be coming out from how the operating system reads the files. So could the results [the differene] also be intertwined with the file system used for a given drive?

Be it how it may, but

is something does not fit into my book

I thought that Mp3tag was suppose to be better than other programs- and hardcore users were here to make sure that it becomes with time

And so I do not understand the dismissal of my finding. Yes, they are issues probably more pending and new features to be implemented, but an existing issue is still an issue

Apparently you were wrong, as after over a month you got zero responses

Just like you were wrong when making that same stupid typo that you have been doing since the 5th grade when you started to learn English: writing down `they` instead if `there`. Shame on you

Perhaps this is no real issue for other users.
I don't have thousands of files with just a length of one or two seconds.
And to be honest: I have serious problems to tell by just listening if a file was half a second longer or shorter than displayed.
But apparently, requirements depend a lot on the individual case.

I think that your findings have not been dismissed - on the contrary they have been confirmed. But you do have a special user case with loads of very short tracks. Hence the lack of response.

I'm not against you in substance (as you can see in my previous posts), but to me this issue isn't so important.

If I am not mistaken then `Mp3` in `Mp3tag` means `MP3 format`, while `M` in `MP3` means `media` and not `music`. If the user is working on audio files like a collection of sounds for some project, then the exact length may be a vital factor. And that would also be true for video [but I have not conducted similar experiment with MKV files]

As for the music solely: it is not only when a piece of it has [around] 2, 4 or 6 second but also when it is considerably longer. An example: if you loop 30 times something that has 15.999 second but get a reading of 15 seconds, then you are off by half a minute, ending with a supposed 7.5 minutes of material instead of the real 8 minutes. Multiple that by 10 different pieces [files] of loops and you loose / gain 5 minutes. But the worst part is,that you even do not know that there is such misreading
` `
` `
I think that enough has been said in this matter. The problem exist but it is hard to notice- and to most users it is irrelevant, especially to those that only listen to music