View Issue Details

IDProjectCategoryView StatusLast Update
0014599MMW v4Properties/Auto-Toolspublic2020-05-25 10:47
Reporterpeke Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionreopened 
Product Version4.1.20 
Target Version4.1.21Fixed in Version4.1.21 
Summary0014599: Track Properties: We should trim start/end TAB character from Metadata
DescriptionTAB 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 Informationhttp://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
TagsNo tags attached.
Fixed in build1870

Relationships

related to 0016653 closedLudek MMW 5 Automatically Trim start/end Space char from Metadata on file import 
related to 0016631 assignedLudek MMW 5 Add option to trim leading/ending space character from metadata like ignore THE option 

Activities

Ludek

2018-01-02 18:36

developer   ~0049471

Last edited: 2018-01-02 18:39

Added the trimming into build 1862.

Also space char, CR (Carriage Return) and LF (Line Feed) are trimmed.

peke

2018-01-03 22:24

developer   ~0049480

Verified 1862

Ludek

2018-01-04 11:58

developer   ~0049482

Last edited: 2018-01-04 17:11

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.

peke

2018-01-04 19:08

developer   ~0049485

Verified 1863

lowlander

2018-02-02 17:12

developer   ~0049573

Please review if removing leading space from metadata (Title) is really needed, some use this on purpose VEM-276-39384.

rusty

2018-02-02 18:50

administrator   ~0049574

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 ?

rusty

2018-02-07 15:02

administrator   ~0049581

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.

Ludek

2018-02-12 12:58

developer   ~0049614

Last edited: 2018-02-12 12:59

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).

peke

2018-04-04 12:40

developer   ~0049867

Verified 1865

zvezdan

2018-06-12 05:29

updater   ~0050519

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?

Ludek

2018-06-12 10:58

developer   ~0050522

Last edited: 2018-06-12 10:58

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.

Ludek

2018-06-12 11:32

developer   ~0050523

Fixed in 4.1.21.1870 and 5.0.0.2112

peke

2018-06-13 02:55

developer   ~0050525

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!!!"

zvezdan

2018-06-13 04:41

updater   ~0050526

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.

Ludek

2018-06-13 08:25

developer   ~0050530

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)

peke

2018-06-13 10:25

developer   ~0050531

As talked further tweaking needs to be done before resolving it.

peke

2018-06-15 23:23

developer   ~0050547

Verified 1870