View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002243 | MMW v4 | Properties/Auto-Tools | public | 2005-12-08 06:58 | 2006-03-15 17:43 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0002243: Track length is reported incorrectly in some cases | ||||
| Description | For some tracks, when the file is a bit longer than average, the track length value that is displayed in the player is correct, however, the 'Length' indicator in the tracklist is several times greater than it should be. Posting a sample track for debugging purposes. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 947 | ||||
|
|
I don't see any track re. this bug uploaded to FTP. Anyway, if it's a VBR mp3 file, similar issues were analyzed many times and always was the track corrupted in such manner, that MM could hardly give better results during scanning of tracks (playback has the advantage to go through more frames). |
|
|
Sorry about that--I just posted the track. What's different in this case is that: -Mr. Question Man and Winamp (Alt-3 and the player) both report the time correctly -The user claims that these tracks started being reported incorrectly during the 2.5 beta period (hard to validate this) |
|
|
Fixed in build 922. - This file contained VBRI tags, not yet handled by MM and so I added it. Now any VBR file with a correct header should be handled perfectly. - I also noticed that in-player mini visualization (those two bars) move slowly for this track. In_wmp3 was modified to fix this. |
|
|
Tested in 923 and found that mm showed 5m21s and stopped playback after 5m21s (even though the track was 7m8s). For comparison: iTunes: showed 7m8s and played it correctly Winamp: showed 7m8s and played it correctly WMP: showed 5m21s and stopped playback after 5m21s |
|
|
I'm not sure what do you mean by 'played it correctly' for WinAmp and iTunes, they show 7:08, but they stop playback in 5th minute because there isn't more to play. The full story is that the VBRI header indicates length of 7:08, I also originally showed this in MM, but then I realized that this is for file of length ~12MB, but this file has actually about ~9MB. I.e. the file was cut somehow after mp3 encoding and so the length showed by MM and WMP is actually 'more' correct than that of WinAmp or iTunes. |
|
|
What I mean is that: -The actual length of the file is 7m8s -Currently, MM and WMP stop playing the file before it ends! Note: my recollection is that MM previously reported a track length of 7:08 in the player, but of ~52minutes in the tracklist. |
|
|
No, I'm pretty sure track length _was_ 7:08 when the file was created, it's indicated by VBRI header in the file. However, now the track length really _is_ about 5:20 because the track was probably truncated in the past. It's evidenced by: 1. WMP playing only 5:21. 2. MM playing and reporting only 5:21. 3. WinAmp reporting 7:08, _but_ playing only 5:21. 4. Mp3 Guess enc tool reports: File size : 9501544 bytes Length : 317.1 seconds 239.719kbit, 12139frames Note the small discrepancy between 5:17 and 5:21 caused by the fact MM and WMP only divide file length by average bitrate, while Mp3 Guess enc tool fully analyzes the file and thus it's result 5:17 is the most accurate for this corrupted file. |
|
|
Verified 923. |
|
|
As reported by users at: http://www.mediamonkey.com/forum/viewtopic.php?t=8368 This issue is still not completely resolved. I'm posting a new sample file that is listed as 2:50 in Winamp and WMP, but 17:46 in MM! (It's by Bruce Springsteen) Sample sent by Ruben Castelein. |
|
|
Fixed in build 947. - This VBR track doesn't have any VBR header and so the correct length information can't be given without scanning the _whole_ mp3 file (btw, WinAmp gave me the same track length as MM). - I added a smart algorithm that scans content of the file and performs even full scan in case there seems to be something wrong. Therefore scanning remained approximatelly the same speed, but is more reliable now and for this track it gives the most accurate length: 2:54. |
|
|
Verified 2.5.2.951. |
