View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003545 | MMW v4 | Properties/Auto-Tools | public | 2007-09-09 05:28 | 2009-02-12 10:43 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | no change required | ||
| Product Version | 3.0 | ||||
| Summary | 0003545: Track# field is sometimes prefixed by '0' and sometimes not | ||||
| Description | As a consequence of the switch in MM 3.0 to a text field, the Track number field sometimes appears as '1' and sometimes as '01' depending on how the track was originally tagged. Is there a way to consistently display this data (on the assumption that this issue will crop up frequently)? Would it be better to have a script for this (if this is only a 1-time issue)? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Yes, I think that a script would be the best solution (downloadable from our web). It could be e.g. configured to use 0,1 or 2 zero prefixes. |
|
|
The reason why I'm reluctant to use a script is that: a) this is going to affect almost every single user (or at the very least, every single current MM user). b) this will occur on an ongoing basis as the user downloads new files Am I incorrect in my assumptions? |
|
|
I don't think a script is the best idea to handle this inconsistancy in the program. The track numbers differs within an album actually. My propose is to; 1) Only use the prefix "0" on tracks between 1-9 in scenearios like; - When auto-organizing, the player skins. (The first because it's easier when file-browsing in Windows to sort the files by track number, the latter one because it is used that way to distinguish any doubt that the track is reall "01" in example.) 2) Use it without the prefix "0" in; - The library viewer and tagging-mechanic. (This is consistant with Amazon) If there are scenearios which doesn't fall under either category, please let me know. |
|
|
My idea of a script was based on the fact that some tracks can have '01' in tags, other '1', some maybe even '001'. A script would be the best way to make user's approach to tagging consistent. If we want to handle this properly in MM UI, we would probably have to add several options: 1. How to show it in tracklist (and other parts of UI)? Show exactly as in tags, or remove leading zeroes? 2. How to store in tags? As entered in UI? Or add 0, 1 or 2 leading zeroes? 3. Some users might possibly want handling of even more advances aspects, like how to handle differences between pop and classical music? Or similar handling of Disc# field? From this point of view, I'd prefer a simple script for handling Track# and Disc# a better analyze user's needs for MM 3.1. |
|
|
It could actually be much simpler than this--just make MM behave the way it used to. e.g.: Add a single option to the Library/Appearance options panel: [ ] Show Disc# or Track# without leading zero This would cause the field to _always_ be shown without the leading 0--just like MM used to (even if the tag happened to contain a leading 0). This would solve 90% of complaints in this area. A script would then be useful for those who really wanted to clean the tag correctly. On the other hand: this goes contrary to MM's philosophy of showing the user exactly what is contained within their tags. Also, it may not satisfy requirements in some cases to have tracks prefixed (which may be a requirement from proper sorting of tracks on some devices). Conclusion: Let's rely on user-generated scripts in the short term and once requirements become more clear, implement a long term solution. |
|
|
I really don't understand this. Why is there inconsistancy within almost every album on my hard-drive if the tags are really displayed properly? |
|
|
This isn't an inconsistency of MM 3.0, it really is how your tracks are tagged. So a script that would correct this would probably be best for now. |
|
|
Setting as resolved, let's reopen in case there don't exist reasonable working scripts. |
