-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrong duration for VBR encoded MP3s #16
Comments
This way of calculation had a purpose. |
I have attached one of the files that gives me issues. I created this file using LameXP (that uses Lame CLI if I am not wrong) with the next settings:
Then I tagged the track with Clementine, MP3Tag and TagScanner... and after that I eventually applied normalization. I suspect that maybe it has to do with the fact it uses ABR (A variant of VBR) and probably supplies aditional information to detect it. |
I have exactly same problem. I attached two sample files. |
Any working solution to this? |
anyone a solution? have the same problem that the duration is not correct with VBR. |
Fixed in 0.0.6 release |
Greetings,
First of all, thank you for the work you have been doing with this library. I have found it very useful. And while so, I have come across a little bug.
If a MP3 is encoded as VBR with a set quality, the duration of the track is not properly calculated by the class.
For example, I have found that a track that should have a duration of 1:34 (~94 secs) it is reported to last ~56.89 seconds instead.
This does not affect tracks that are not VBR encoded.
Further looking into the code, I found out that Quality is used to calculate the $samples_per_second in the lines 295 to 297 in MP3Info.php:
After doing some tests, I found out that the "time" difference was related to the quality. In my case, the MP3 had a quality of 60, so the time was 60% shorter than expected.
I am using the dev-master version of the library.
Thanks in advance.
The text was updated successfully, but these errors were encountered: