View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002655 | MMW v4 | Synchronization | public | 2006-09-18 20:50 | 2006-11-30 19:37 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0002655: Support for iPod's 'gapless' mode | ||||
| Description | The new iPod firmware supports gapless playback for tracks that have been identified as part of an album to be played gaplessly. Ideally MediaMonkey should offer some sort of equivalent. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1012 | ||||
|
|
I'm not sure if we need this. According to http://docs.info.apple.com/article.html?artnum=304362 , for iPod this settings makes no difference, it's only for decision whether iTunes will crossfade the track or gaplessly join it with the next one. In MM, I'd propose to make this decision automatically, i.e. don't force user to set this flag for every track, but decide based on track genre, e.g. 'audio book' tracks wouldn't crossfade, even if crossfading is enabled (and anything that isn't crossfading would be played gaplessly - at least as much as technically possible). An interesting reading: http://en.wikipedia.org/wiki/Gapless_playback We should report our decision to forum, namely http://www.mediamonkey.com/forum/viewtopic.php?t=12254 . |
|
|
So to make sure I understand: Behaviour in MM (bug 2545): Gapless: Always enabled (i.e. no config?) Crossfading: Configurable globally (--except global config is ignored for certain defined Genres (...book, podcast, spoken word, etc.) which never crossfade. Behaviour in iPod (this bug): Gapless: Always enabled Crossfade: Never enablde (since it isn't supported) |
|
|
Generally speaking yes, just some clarifications: Behaviour in MM (bug 2545): Gapless: Always enabled, unless Crossfading is enabled. There's no need for any special configuration, except possibly for silence removal on begining/end of track that would allow 'better gapless' mode for tracks where some gap is introduced e.g. by mp3 encoder (see wikipedia link above for a technical explanation of this). Crossfading: Configurable globally (--except global config is ignored for certain defined Genres (...book, podcast, spoken word, etc.) which never crossfade. Behaviour in iPod (this bug): Gapless: Always enabled (and working on some models only) Crossfade: Never enabled (since it isn't supported - yet? Maybe some newer models will...) |
|
|
Question is, whether iPod needs some information to be written (I don't know what) in order to play gaplessly, according to discussion in the forum, it might be necessary. A good test might be to rip a CD with live music (so that there aren't gaps between tracks) to wavs and mp3s, try to synch using MM and then using iTunes and test whether iPod plays the album gaplessly in all/some/none cases. |
|
|
I have just got a test with one of my mp3s, I splitted it into two parts and symchronized both to my iPod nano by using MM. Result: iPod plays it absolutely fluently (gaplessly). |
|
|
Until we get another information, it seems there's nothing to resolve. |
|
|
I must correct myself, in my previous test it were WAV file parts (not mp3), but if I converted this wav parts to mp3 parts by using MM and tried play this mp3s - there were a small gaps between this parts! It really seems that convertion to mp3 add a small gap to the converted file. |
|
|
Based on test to synchronize these mp3 parts by using iTunes 7: iTunes 7 analyzed all my songs in iPods without any configuration, it takes about 4 minutes and iTunes status bar shown 'Determining gapless playback information'. After this process the mp3 parts played gaplessly. i.e. iTunes removes silence at the end of tracks somehow, but not physicaly, the mp3 files aren't physicaly changed. |
|
|
Ok, so the situation is clear now: 1. Some mp3 decoders introduce zero samples in the begining or the end of track, e.g. our in_wmp3.dll does (but in_mpg123.dll doesn't). 2. This silence (gap) then causes that playback isn't truly gapless. However, setting 'Remove silence at the beginning / end of track' in output plug-in fixes the issue when playing track back in MM. 3. For playback on iPod iTunes sets three fields for each track: - total # of samples - # of zero samples in the beginning of track - # of zero samples in the end of track Based on this information iPod can play tracks gaplessly. 4. We can easily do the same as iTunes does, i.e. write number of samples to iPod DB, problem is when to analyze tracks so that we know what to write to DB. We could do it as iTunes, i.e. somehow analyze the tracks on background. However, personally I find it as quite an overkill because it would require to analyze tracks on every PC, even without iPod and this information isn't needed for anything else than iPod (output plug-ins can do it on the fly). So maybe we could analyze tracks just during synchronization to iPod and save the values, but it could slow down iPod synchronization then... |
|
|
A possible approach to gap analysis would be to change 'Analyze Volume' to 'Analyze Audio', and it would do the following: a) volume analysis b) audio fingerprint generation c) gap analysis If we want (though I don't think this is necessary), in the config panel there could be something along the lines of: 'Analyze Audio' analyzes: [x] Volume [x] Fingerprints [x] Audio Gaps When bug 0000097 is implemented, this feature would automated into a background process. e.g. '[ ] Analyze Audio for unanalyzed tracks'. |
|
|
Fixed in build 1012. - For mp3s encoded by some newer Lame version (including those in some newer versions of MM) it works 'losslessly', i.e. tracks are properly tied together sample by sample. - Other mp3s work well too, but their correct playback can't be fully guaranteed. - The analyzation part I implemented is currently so fast that there wasn't any addition step necessary, the necessary short analysis is done on the fly while synchronizing to iPod. - We just might need to do the same for m4a tracks later... |
