its almost insane that anyone would even argue this point. its like one (vast common sense majority) side saying "don't stare into the sun" and the other, (theoretical minority) insane side saying "no, stare into the sun."
just because you CAN stare into the sun, doesn't mean you should blind yourself. this is just PAINFULLY obvious! Philip Meyer;645139 Wrote: > I say no, it's fine and consistent with other apps, and I welcome the > slight speed improvement of not stripping every tag string. knowing you as i do, i'm sure you don't have any leading or trailing spaces, and since you don't, there will be no loss of speed to worry about. this is how it ALWAYS was done, and you never complained then. respecting them is an undesirable, unintended side effect of the diacritics fix. the point here is to just make things as they ALWAYS were prior to that fix. Phil Leigh;645140 Wrote: > All strings/fields used as keys/foreign keys/search items should be > left/right space-trimmed. No need for a debate. Leading/trailing spaces > have no typographical or informational value and are pure noise - and > are always an error. No need for any complex options. > > You'll note that no-one complained about how this used to work... exactly correct. not only is it noise, but its useless noise, invisible noise, and potentially problematic noise. i have found that some rippers, for some reason, put 20 spaces or so into the comment field... no idea why, but they do. if you all check your files, you may find other visibly blank fields are actually just spaces, not truly blank. now, if we are to worry over nonsense like how much slower the scanner is trimming off leading/trailing spaces, what about how much slower the scanner is putting SPACES as the only entry to a tag field? what about the DB performance hit of having to parse extra, yet useless data when doing queries? like i said, are we going to have albums of 3 spaces? 5 spaces? 7 spaces? AA of 4 spaces? comments of 20 spaces? 15? trailing spaces are not anything other than noise, plan and simple. Philip Meyer;645145 Wrote: > >All strings/fields used as keys/foreign keys/search items should be > >left/right space-trimmed. No need for a debate. Leading/trailing > spaces > >have no typographical or informational value and are pure noise - and > >are always an error. No need for any complex options. > Untrue. > If it were true, there wouldn't be any leading/trailing spaces in any > tags anywhere in the world, because they would have already been > trimmed by all other ripping/tagging software. thats a laugh, and TOTALLY untrue. there's no difference between that logic, and the logic of saying "i jumped off the bridge b/c everyone else was doing it." thats lemming logic. instead of justifying an actual reason of merit, you simply pointed to other apps bad behavior to justify this. thats not the same thing, or logically worthy. Philip Meyer;645145 Wrote: > But as I have demonstrated, all software that I have tried is not > messing with the tag values - they are honoured as entered. > > If a user wants a space at the end of their artist name, let them have > it. If a user doesn't want that effect, because they got dodgy tags > from a dodgy source, they can edit it with a tag editor. thats always the case. a user could always alter their tags. the point here isn't whether a user can or can't do that, its whether the app should do it or not. there is no compelling reason for the app to respect them, none. it simply doesn't exist. this isn't a diacritic, or a case difference, where at least you can SEE the difference. this is a trailing BLANK INVISIBLE SPACE. that isn't data, its NOISE. there is no reason for a smart app to not make such an obvious interpretation as that. Phil Leigh;645230 Wrote: > Sigh. > > Of course it's true. > What is the informational or typographical value of leading or trailing > spaces? zero! blank! nada! zilch! Phil Leigh;645230 Wrote: > The fact that they haven't been trimmed by other software is completely > irrelevant - 2 wrongs don't make a right! correct. Philip Meyer;645346 Wrote: > >What is the informational or typographical value of leading or > trailing > >spaces? > > > If there is no benefit of leading or trailing spaces being there, then > delete them from source. > > What are we going to do - delete white space from every possible tag, > even though it only matters for artist/album tags? i think AndyG is more than smart enough to know which tags to apply the logic to, and if its not perfect it can be fixed. you also dodged the question. you gave no answer to what the value is. Philip Meyer;645346 Wrote: > > >The fact that they haven't been trimmed by other software is > completely > >irrelevant - 2 wrongs don't make a right! > > > Until you consider iTunes and MusicIP import plugins, when the data > won't then match if it needs to compare source with DB content. There > may be the occasional thing that doesn't match between the two apps > that will cause problems. GREAT POINT, UNTIL YOU CONSIDER THAT THIS WAS NOT A PROBLEM BEFORE THE DIACRITICS FIX. Philip Meyer;645346 Wrote: > > >You are not looking at the problem from a data modelling/database > >design perspective. It's only when tags get used in that context > that > >this becomes an issue. > So if the problemmatic tags were fixed at source, it would be solved in > all apps. > > A library of 100000 songs with 10 tags in each file would be 1,000,000 > LTRIMs and RTRIMs, to fix what could be a small handfull of mistakes at > source. we don't know how exactly the fix would be enacted, so it may only be invoked when the condition is present, and we don't know how much, if at all, this would impact scan time to begin with. also, scanning a tag isn't the same as running a process on the data post scan. it all depends on implementation. Philip Meyer;645346 Wrote: > Or set up a filter in Mp3Tag to find tags with leading or trailing > spaces, and a macro to remove them and run it as a once-off on every > matching file. Problem then solved for every app, and keeps the scan > time down. most users just want a good experience given a reasonable looking set of data. most users won't even understand spaces are the issue, much less what to do about them. as you said yourself, a separator character with a space might as of right now, cause a problem where: XXX;YYY won't be equal to: XXX; YYY since it could (and probably does) result in a second unintended " YYY" artist. w3wilkes;645356 Wrote: > If the spec for the tags doesn't state that leading/trailing blanks are > not allowed in a given tags content then I'd say they are allowed. of course they are allowed. thats not the question. the question is should an app differentiate based on a space, (allowed or not)? i think the answer is a clear and obvious NO. as said above ad nauseum, they are useless noise, and totally unintended, and serve no purpose whatsoever. -- MrSinatra www.lion-radio.org using: sb2 & droid (my home) / duet & ipeng (parents' home) - sbs 7.5.5b - win7 & xp pro sp3 ie9 - p4(ht) 3.2ghz, 2gig ram - 1tb wd usb2 raid1 - d-link dir-655 - 49k+ mp3/flac ::VOTE FOR 'BUG 15604' (http://bugs.slimdevices.com/show_bug.cgi?id=15604)!!!:: ------------------------------------------------------------------------ MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336 View this thread: http://forums.slimdevices.com/showthread.php?t=88154 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/ripping
