View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014599 | MMW v4 | Properties/Auto-Tools | public | 2017-12-23 21:14 | 2020-05-25 10:47 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 4.1.20 | ||||
| Target Version | 4.1.21 | Fixed in Version | 4.1.21 | ||
| Summary | 0014599: Track Properties: We should trim start/end TAB character from Metadata | ||||
| Description | TAB Character should be automatically replaced in filenames and metadata with SPACE and should be Front/End TRIMMED. Possibly add INI switch for backward compatibility. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=88828 User missing trailing CR: http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=90088 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1870 | ||||
|
|
Added the trimming into build 1862. Also space char, CR (Carriage Return) and LF (Line Feed) are trimmed. |
|
|
Verified 1862 |
|
|
Re-opened, I've run DUnit tests today and the fix caused constant failure of the following tests: Internals > TTestMasks > TestMaskFunctionsNested Library > Podcasts > TTestPodcast > test4_05_Podcast_Subscribe StressTest > TTestStress > TestStressPlayback Fixed in 1863. |
|
|
Verified 1863 |
|
|
Please review if removing leading space from metadata (Title) is really needed, some use this on purpose VEM-276-39384. |
|
|
I have a feeling that that he might be the only person doing that and that in general, it's a better idea to not permit leading/trailing spaces. Couldn't we just suggest an auto-tag rule to replace leading spaces with dashes ? |
|
|
Upon further discussion with Martin, and based on the fact that leading spaces _are_ permitted in filenames, it seems that we probably shouldn't prevent leading spaces in MM. If there's another release of MMW we can fix it, otherwise include the fix in MM5. For now, the workaround of replacing spaces with _ might be the best approach. |
|
|
The trimming was originally introduced in MM5 for consistency, because in MM4 some fields were auto trimmed (like artist, composer, genre), but some fields (like title, album) were not trimmed which caused issues in grouping and data inconsistencies, some tracks were from ' album1' and others from 'album1', but actually get assigned just one instance of 'album1'. I agree with Rusty that the user from VEM-276-39384 might be the only person doing that and that in general, it's a better idea to not permit leading/trailing spaces -- in order to not have the library data messed up (i.e. without a need for manual remove of leading/trailing spaces). |
|
|
Verified 1865 |
|
|
You shouldn't ask for reasons why users use some things. Your comments how only one user wanted such thing are just funny. How do you know that it is just one user? Maybe there are more of them that want such thing, but didn't want to bother commenting that in the Forum. I am the one of them which don't don't like MM trimming tags. The original poster asked just for a removal of the Tab character, and you added something unwanted. I could understand your explanation about trimming of the space characters and CR+LF in Album, Artist or Genre, but there is no excuse why you implemented that for Title. And especially there is no reason why you implemented that on Comment. The single-line fields could have trimming of CR+LF, but not the space character. The multi-line fields like Comment and Lyrics should not trim CR+LF neither. You should understand that there are many people who use their media files not only in MM, but also in another software that permits such things as CR+LF in the Comment. Actually, could you state at least one program that has the same behavior regarding trimming of Comment as your? |
|
|
OK, based on the feedback re title and comment (http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=90088) it makes sense to not trim CR+LF and spaces for these fields. And trim them only for album, artist and genre for the reasons described by me above. |
|
|
Fixed in 4.1.21.1870 and 5.0.0.2112 |
|
|
Re-opened. As Space, TAB, CR , LF are non visual characters https://en.wikipedia.org/wiki/Whitespace_character Keeping them breaks Search for all fields that support "starts with" and "ends with" even RegEx handle them specially https://en.wikipedia.org/wiki/Regular_expression#Character_classes , also it complicates indexes on fields like Track/Disk #, date, year, ... Usually a common problem is double space characters in filenames like "Queen__-__I want it all" which result in mask "<Artist> - <Title>" can tag files wrongly where "$Trim(<Artist>) - $Trim(<Title>)" would not, but it fail when you Auto-tag from Filename and you need to corerct/execute such action manually on all fields. I Completely agree on Lyrics and Comments that trailing but all one line fields should have Non Visual Characters trimmed from Front/End. Regarding Lyrics and comments having CR+LF at start is user preference (personally I like that first char is Visible character). Here is non MMW example of common mistake users make in Word processing where when they want to make some text Right align the often Space Align by entering tens of space characters that looks ok on their PC but if you change font or have/change page margin differently it breaks text. Same goes for text printing in different formats eg. Letter -> A4 or via verso. Such errors are complicated to spot and takes time to correct. If you ever took some text to print in a magazine the bolded note for all writers is "Please do not format your text, especially do not ident, make manual line cuts, set linespacing, numbering with regular characters or spaces!!!" |
|
|
Peke, I am not sure what you are suggesting, but I am not talking here about Search or filenames and Auto-Tag from Filename or Auto-Organize. We should talk about what users intentionally enter into their tags, be it using MM or some another tagging program. If I enter CR+LF on the end of the Comment using mp3tag or whatever else program and open such file in MM, I expect that it keeps such Comment intact. If I do the same thing in MM, i.e. if I add CR+LF on the end of Comment using the Properties dialog box and reopen the same file in Properties, I expect to see what I typed previously. I don't want a program messing with my typing in tags. It seems you forget the simple fact: 1. with the old behavior of the program, the users who don't like CR+LF on the end of Comment have an ability to trim them manually. 2. with the new behavior of the program, the users who want CR+LF on the end of Comment cannot do anything to keep them. It is your responsibility how your program will do Search or Auto-Organize or Auto-Tag of files with such tags. By the way, such characters as space, TAB, CR & LF are piece of cake if you use regular expressions, even if they are multiple in series. The RegExp Find & Replace add-on could find files with such tags and clean them without any problem. It already has the predefined presets for that. If you want, you should do the same thing internally before any Search or Auto-Tag. But only internally, without changing what users already typed on purpose. |
|
|
I guess that the implementation in upcoming build 1870 is a good compromise: - it trims TAB from all fields (original issue) - it trims spaces and CR+LF from album, artist, genre fields and thus solves the grouping inconsistencies described in my note 0014599:0049614 - allows leading spaces and CR+LF in comment/lyrics/title fields like in other apps (like iTunes) - the user complaints satisfied So I would leave it as is for now, we can adjust it further for MM5 (in case of need) |
|
|
As talked further tweaking needs to be done before resolving it. |
|
|
Verified 1870 |
