>it would be safe to assume in 99.9999% infinity cases that the space is >not intentional. > Not safe to assume, but probably true that in the majority of cases, trailing spaces are not intentional.
>> Some people may add spaces to make two albums of the same name unique (a >> bit silly, but not inconceivable). > >i'd be interested to see where this either: > >1. has ever happened or is the case >or >2. is well justified? > It has happened - I've read forum posts where people have suggested it, eg. to fix the "Greatest Hits problem", etc. It is of course a really bad idea, and I would never suggest it. But if people have done it, and then SC starts to strip them out, they will moan that a new release is broken, buggy, etc. >i think it is MUCH more likely to be the case that someone doesn't know >the space is there and they get bad, confusing results as a result... If they only use SC, that would be likely. But if they use the music in other apps that don't (and I would assume most don't), it would be inconsistent with them. >VA detection is standard? greatest hits logic is standard? other >logics standard? > Most apps don't have Compilation support. SC does, so it needs to detect such albums. I don't think of that as non-standard, but extra functionality. >i am suggesting some common sense that has virtually no downside and >plenty of reason to do it. > Plenty of reason not to, too. >and i am not saying the scanner has to do it, it could be a post scan >operation. > Post-scan is too late - albums have been created by then. It would be even slower to read everything back out of the DB, find trailing spaces, remove them and then decide whether to join the songs on that album to another album. Then it would be necessary to determine if the album should be a compilation, if the artists being merged in are different. >please tell me, and this should be rich, HOW WOULD YOU KNOW? how would >they indicate a BLANK SPACE? for that matter, if it was multiple >spaces, how would you indicate how many EXACTLY? > How did people know that the Beatles created an album called "The White Album"? They never did. It has no name. Maybe they called it <space>. >i agree that fixing the tags is best, it always is, but this is a case >where a avg user could have a lot of trouble. > It's not a lot of trouble. If they did have a space at the end of some songs, they'd get two albums, listed next to each other. The albums/songs would still work, but not presented as one thing, because of miss-tagging. Fix the tags, and the music will be listed correctly. That's how it should be. >i'm the first to admit i don't really understand how SC works when it >uses itunes or musicip. > >i take you are saying when using those sources, it doesn't fill the >regular SC DB? is that right? > It takes the metadata from those applications and imports it into the SC database, merging with information that has already been inserted into the SC database (eg. using SC's own scanner). Actually, it's probably okay, because the scanner uses the filename to match the music (it needs the filename in order to play the music after all). >yes, thats a good idea. i will do that if needed, but as i've been >aware of the issue in winamp for a while now, i've manually >straightened out the issue pretty much. Just like anyone else would - fix the tags. >SC does already remove/ignore/deal with trailing spaces. (don't >ask me how or when, b/c i have no idea) > Are you sure? >i have "Help!" by the Beatles, and i figured lets see what SC does. > >so i added a space to the end of the album name in winamp on half the >tracks, and got winamp to do its annoying thing and show it as two >albums, (both of which appear as "Help!" but one of which is actually >"Help! " > Did you change id3v2.3 tags? Have you got id3v1 tags still, because they may be read before the other tags? Ensure you do it with only one tag format/version in the files. >so Phil, i'm sure you're torn, which position to take now? If it does it, then I see no reason to take it out, because people would complain if it changed their library data. It's a pity if it does, because it will be slowing the scanner down unnecessarily for most people, and I'm all for making the scanner as fast as possible. _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
