View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005421 | MMW v4 | Player | public | 2009-03-26 20:00 | 2011-02-13 21:13 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Target Version | 4.0 | Fixed in Version | 4.0 | ||
| Summary | 0005421: Player seek bar is out of sync with audio | ||||
| Description | When MM is playing numerous short files (3-4sec), it can be seen that the seekbar and the audio quickly get out of sync. Moreover, some audio tracks appear to be cut off slightly. Note: tested with .wav files (posted to ftp), and default output plugin. Disabled crossfading and silence removal in the output plugin. | ||||
| Additional Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=37780 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1345 | ||||
| related to | 0005579 | new | Short WMA files (< .2s) don't play |
|
|
Ludek, please check out whether it could be somehow related to out new handling of WAV files, whether it's WAV specific at all, etc. |
|
|
This problem isn't WAV specific, same problem appears for mp3 too. The problem is specific to output plugin, out_wave.dll works fine, but out_MMDS.dll makes playback 1 second shorter. |
|
|
Just to clarify, I'm not sure what you mean by 'our of sync', I only see that audio is cut off 1 sec earlier. However, this is actually by design of out_MMDS.dll plug-in. This 1 sec earlier termination of playback is there in order to let MM to start decoding of the next track, which can then smoothly continue when the first one finishes. This is needed because of the design of WinAmp input plug-ins, that we still use. So, the summary is: I could remove this 1 sec earlier termination, but we would lose gapless playback. I can make the inteval smaller, but probably not much, at least some 500ms should be there. |
|
|
By 'out of sync' I mean that: a) the seekbar never goes until the end of the track b) the seekbar always disappears near the end of the track, even while audio from the track is still playing Re. audio being cut off, I'm a little unclear--audio should never be cut off unless it's just silence that's being terminated. Or are you saying that this only occurs if the 'remove silence' option is enabled? |
|
|
Ok, then 'out of sync' and 'cut off' is the same issue. Technically, there isn't any audio lost (of cut off), all samples are played by MM. Here is what happens: 1. There is a track A playing having length 0:34. 2. At 0:33, MM UI switches to the next track B. 3. The audio of track A properly continues playback until the end of track (i.e. 0:34). 4. Track B is already pre-decoded at this moment and so when track A terminates, track B starts playback continuously, without any delay. |
|
|
I've reviewed this again in build 1344, and the current behavior of the seekbar isn't quite right. In the example previously described: 2. At :33 The MM UI (the seekbar) should not switch to the next track B unless track B has started playing prior to the end of Track A (i.e. when crossfading is enabled). A second, related point is that when track B starts playing, the seekbar stutters (i.e. it appears briefly, then disappears, then re-appears further forward). |
|
|
A behavior similar to the described one can happen if: 1. Exclusive mode is used, and 2. Automatic format is used (instead of a specific one), and 3. The two consecutive tracks have different audio samples format (e.g. 44100 vs 48000 Hz), and 4. Crossfading is enabled. Can you confirm this is case? If so, I'd rather leave it since it's a specific case which doesn't have a simple solution. If not, please include as many details as possible - I don't see the original description of the tracks used for testing, their length, etc. |
|
|
This bug occurs for all 3 output plugins (though it's much more obvious with WASAPI and mmds), even with all output plugin options disabled, and has been verified to occur at least with WAV, m4a, and mp3 files. It's primarily a visual bug, and it's easiest to replicate when the test files are short (e.g. 5-8 s). If you don't observe it, I can create a video. |
|
|
I've noticed the stuttering at the beginning of videoplayback too. It occures sometimes. I've made a little debugging and video plugin was sending correct playback position data. |
|
|
Fixed in build 1345. Reproduced the issue in WASAPI plug-in, audio and display could really get out-of-sync as much as several seconds. I haven't tested MMDS extensively, but I suppose that it works much better and even if there's an issue, it's negligible and isn't worth fixing. |
|
|
Verified 1348 |
