View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001848 | MMW v4 | Properties/Auto-Tools | public | 2005-03-09 12:04 | 2007-09-11 17:05 |
| Reporter | jiri | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | have not tried |
| Status | feedback | Resolution | reopened | ||
| Summary | 0001848: Track# Field doesn't display what's in the tag (was Add leading zero to track# field in ID3v2) | ||||
| Description | As reported for example in http://www.mediamonkey.com/forum/viewtopic.php?t=3745, some users need to store track# in ID3v2 with leading zero (it's stored as a string, not number). This has been fixed, but in a manner that doesn't really solve the problem since there's no user feedback about what format a track# is stored in (i.e. whether it is prefixed by '0' or not. Leaving this bug open, but as a 'high' priority issue (it's not that critical). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 851 | ||||
|
|
Fixed in build 851. |
|
|
The current implementation behaves exactly as designed (ID3V2 tag is saved with '0' prefix if entered, but UI doesn't show anything), however, I think that this design is very flawed. Problems are: 1) The logic applies only to ID3V2 tags. Filetypes other than MP3 are handled in a different manner. Why? 2) There is no way for the user to see whether a track is prefixed with a '0' or not, which means that they have no way of knowing whether it needs to be changed. 3) Because of 2), 'Unsynchronized tracks' will show tracks that appear totally in synch but aren't because of a missing 0. Maybe I'm missing something, but this seems very strange to me... |
|
|
The whole idea of the fix was as follows: - Track #s are simply numbers and so there's no reason to change their appearance in MM. - For >99% of users it absolutely doesn't matter if leading zero is there or isn't, but some applications or portable players don't understand ID3v2 field 'track#' as number but take it as a string and so sorting isn't ok unless the leading zero is present. For that reason it seems to be a good idea to always store leading zero and don't bother user with this (don't show anything about it in MM's UI). - As for 1), you are right, but I haven't heard about any application or portable player having this problem with other than ID3v2 in MP3s. Although generally speaking this could happen with other formats as well, I think it wouldn't since this is only problem of some older/not well written applications or devices. - As for 2&3), again you are right, but I don't think it's worth bother user with some settings/UI options about this. Should a user be insterested in this (and as I wrote <1% will be), he can simply Synchronize tags for his tracks and all will be ok. So this issue possibly only deserves an entry in upcoming FAQ. |
|
|
Ok. Rather than opening another bug, I'm just leaving this one open as a 'high' priority issue. |
