>its almost insane that anyone would even argue this point. And yet you continue to argue.
>(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." > It's nothing like that, but irrelevant anyway. It more like the government issuing the whole population sunglasses and saying you should wear them all the time just in case you should look at the sun. >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. > No actually now that I've managed to actually complete a scan in 7.6, I have indeed found a couple of artists where I had a space on the end. Thanks to 7.6, it made this ERROR in my tags obvious, and I've now fixed it, thus fixing the ERROR I had in my other apps. >this is how it ALWAYS was done, and you never complained then. I didn't know I had a problem then. Now I do, and now I haven't got a problem any more. Is it really a big deal? It's simple to trim them once and for all, and never have to worry about SBS or any other app having a problem ever again. >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? There's no performance hit to consider for copying data from tags into fields in the DB without guessing that the content needs additional treatment. If you don't want the spaces in the comment field, then delete them, then you don't need to worry about the extra space being stored in the DB. >this isn't a diacritic, or a case difference, where at least you can >SEE the difference. this is a trailing BLANK INVISIBLE SPACE. > Oh I see, thanks for clearing that up. I didn't know that space characters were blank and invisible. Wow. Now I feel enlightened, and my views are completely different. NOT! >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. > Correct - it's wrong for those characters to be there, and it's wrong to assume they should be stripped. What the user has entered should be how they are stored and viewed. I've even heard of people purposely adding spaces to the end of items to make them be treated as a different entity. eg. if two albums by the same artist are meant to be different, and a user (rather stupidly) wants to make them different by adding a space to the end of the second, then let them do it. >> 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. > Do you know that? There are many reported issues that haven't been fixed; it could well be that there's been an issue with items not matching between the two apps, which could now be fixed. >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. > They they would have the same problem in iTunes, iPod, iPhone, and be used to it. >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. > Perhaps, but I'd assme "; " would be the separator. >as said above ad nauseum, they are useless noise, and totally >unintended, and serve no purpose whatsoever. Then stop saying it. We all get the message/argument. There's just a decision to be made by Andy. Leave it to him to decide now. There's nothing more to add to the conversation. _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/ripping
