Wrong detection of length of MP3 files
Free media player with support for Youtube
Brought to you by:
rvm
Menu
▾
▴
#358 Wrong detection of length of MP3 files
For some mp3s with variable bitrate, a wrong length is detected. Consequently, the values for the progress bar are faulty. Similar as described in Bug #2865798, the playback stops, when one seeks outside the real length of the file. Please note, that mplayer alone detects the correct length of the file and seeks correctly. I do not know the internals of smplayer, but it seems that either the media length is incorrectly queried by smplayer (maybe it queries a nontrustworthy data source) or it uses its own algorithm to determine the length (which in this case is flawed). Note, several other command line tools were able to correctly determine the real length of the example file. If you want, I can upload said MP3 file, however it is copyrighted music. Please fix this error. It makes SMPlayer impossible to use as an MP3 player.
smplayer takes the length from the ID_LENGTH tag from mplayer. If it's wrong, it's a problem of mplayer.
Anyway it would helpful a sample mp3 file with the problem you describe.
I know, sometimes even mplayer does not return the correct size of an mp3. Still one is able to seek within every file, probably because it does not use "time" to specify a location within a file, but maybe "frames" or some kind of structural unit. If mplayer supports seeking by specifying a relative position (such as "52,34%" or "frame 10592 of 20238"), the seeking should be changed in that way. For instance, if the user wants to jump to the middle of a song, either "50,00%" or "frame 10119 of 20238" should be submitted to mplayer instead of a value based on the length of the whole file, which is sometimes not correctly determined.
The file in question won't upload. (13MB may be to big for sourceforge). Do you accept any file hosters? Otherwise I would have to look for another, smaller file with the problem tomorrow.
Initially smplayer used a percentage for seeking. For me it was ok, but people complained because seeking was not very accurate because the slider could only jump to 100 positions in the movie. So I changed it and now seeking uses time.
Anyway it's still possible to compile the old code, edit src/config.h and delete the line that says:
#define SEEKBAR_RESOLUTION 1000
I've uploaded a test MP3 here: http://www.file-upload.net/download-2203602/test.mp3.zip.html
Password: sourceforge.net
Concerning seeking by using a percentage: Can you make this a runtime option? Is it possible to make it more accurate by using fractions?
This is the related mplayer bug: http://bugzilla.mplayerhq.hu/show_bug.cgi?id=465
So basically, you canot trust ID_LENGTH ... It's very frustrating to see that even small tools such as http://sourceforge.net/projects/mp3check/ get this right, while such a huge project like mplayer doesn't...
> Is it possible to make it more accurate by using fractions?
I didn't think about this possibility, but it seems it works.
So then revert back to seeking by percentage and use length/time only as information to the user. If mplayer gives a wrong ID_LENGTH, it will show wrong values to the user, but at least seeking would work as it should.
Check svn r3417.
Works perfectly for me. Thank you very much for your quick support :-)
There is a flaw I noticed (which may or may not be related to the changed you made): When I left click on the progress bar at a certain position, I usually expect to seek to that position. Currently this behavior is broken (it doesn't jump to that location, and sometimes it even doesn't skip forward).
Sorry, but I have to add another observation: The position of the progress bar gets reset after seeking by drag'n'drop. The seeking itself works fine but right after you raise the left button, the knob of the progress bar jumps to position that seem to indicate that there is still "time" used in the computation where to position the knob.
I think "time" is used in the update code of the progress bar
> There is a flaw I noticed (which may or may not be related to the changed
> you made): When I left click on the progress bar at a certain position, I
> usually expect to seek to that position. Currently this behavior is broken
> (it doesn't jump to that location, and sometimes it even doesn't skip
> forward).
I can't reproduce this problem. Did it happen too with the previous version?
> I think "time" is used in the update code of the progress bar
Yes, smplayer reads the time from the mplayer status line to update the slider. The percentage is not printed there.
For me, mplayer does print the percentage:
-------------------------------------------------
> mplayer -identify test.mp3
:
ID_LENGTH=613.00 // here it's 613 ?
:
A: 7.1 (07.1) of 230.0 (03:50.0) 2.0% // here it's 230 ???
-------------------------------------------------
The discrepancy between 613 and 230 causes the "progress bar handle jumps back to some akward position" bug. Why don't you use 03:50.0 or 230.0 instead? Of course this information is only available right after playback has started.
> Did it happen too with the previous version?
No, the version 0.6.8 does not show the "jump to location" bug. But SVN-r3417 does (tested with test.mp3)
> Why don't you use 03:50.0 or 230.0 instead?
It seems that time may be wrong too.
I tested with a mp3 file. ID_LENGTH says 2029.00, the time in the status line says 507.0 (08:27.0) but the song ends at 465.1 (07:45.1).
What a mess. Still, the "length given in the status line" is probably more useful than ID_LENGTH because that is the time mplayer itself uses to compute the progress and which is referred to by using percentages. Even if one would use an external tool to get the exact length of the a MP3 file, on would have to use the "length given in the status line" to communicate with mplayer.
I have to apologize: jumping to certain location by clicking on the progress bar does work (in old versions as well in SVN-r3417. I just got confused by the fact that the knob immediately jumps back to its time-based update position. For me, it looked like it didn't reliably jump to a location, but from the perspective of mplayer, it was already at that position after the second and third click. So the only existing problem is the ID_LENGTH-based update (instead of the "length given in the status line")