Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

So, as most of you are undoubtedly aware, the iPod app in iOS is case sensitive for some dumb reason and you can't turn it off.  Who would ever choose this as a "feature" is beyond me, but what ends up happening is that I end up with multiple "sets" of the same artist or album on my phone.  That's pretty annoying.

I hoped for a long time that Apple would fix what seems to be an obvious flaw in their software (iTunes, after all, doesn't display the panes in a case sensitive way), but now that iOS 4.1 beta is sampling and there still don't seem to be any changes, I'm tired of waiting.  I went through last night and fixed all of my "a, an, & the" articles manually (those are mostly what messes it up).  Now, I just have a random smattering of things like "Death Cab for Cutie" vs. "Death Cab For Cutie" and "nine inch nails" vs "Nine Inch Nails" along with similar things in the album tags.

Is there any way to build a View Scheme that can somehow show me which files have [Artist] or [Album] tags that match but don't match when the search is case sensitive?

I know I could just select-all and then do a Clean Tags command on them (and I will if I have to), but some artists and albums I do prefer to have special capitalization (nine inch nails would be a good example, and radiohead would be another).  So, if I go this route I'll have to either give up on that silly conceit or manually go through and fix them after the great capitalization fix.  Plus, what about next year?  I'll have a new pile of them to sort through and deal with...

[Matt]

Sorry, but there's no way to force Media Center to be case-sensitive.

Your 'Clean Tags' idea is the only solution I can think of.

[vagskal]

When I tried to get the capitalization of prepositions unified I created fields with expressions like this to find the files with "wrong" capitalization:

Code: [Select]

If(IsEqual([Album],/ Of/ ,7),1,0)
I had to type in the prepositions manually one by one of course.

[gappie]

im not really sure what you are after.. it is finding where the information in the tags is different from the information in mc concerning capitals?
would this not give a list where the album tags have different capitals as the tags in mc

Code: [Select]

[Media Type]=[Audio] [=isequal([album],tag([album]),0)]=0try this on a small set first. since it has to read the physical tags.

 
gab

[glynor]

it is finding where the information in the tags is different from the information in mc concerning capitals?

No, I don't really care about the file tags at all, just the MC library tags.  I have MC manage the file tags, and they should all match the MC library, and even if they don't, when I sync to my generic handheld folder, it embeds the proper tags itself.  Some of the files might not even HAVE file tags (they might not be media types that support file tags).  I just have this scenario:  Imagine that 90% of my tracks by Mr. Reznor are tagged in all lowercase.  So, you'd have [Artist]="nine inch nails" and [Album]="the downward spiral" and so on and so forth.  This is fine for those, but then I have 10% of the tracks mixed in that might be tagged "Nine Inch Nails" and "The Downward Spiral" or even "Nine inch Nails" and "the Downward Spiral" or even "nInE iNCh NAiLs" or something absurd like that.

Normally, you wouldn't care.  MC handles this beautifully, and the panes seem to show it whichever way is more prevalent (I'm guessing, but that's how it looks to be for my data).  Unfortunately, stupid Apple cares.  The iPod App considers "Nine Inch Nails" and "nine inch nails" to be two separate artists, and then "the Downward Spiral" and "the downward spiral" to be two separate and distinct albums.  It lists them separately in the app, and so there's no way to play the full album if they're separated that way.  It is dumb, but that's the way it is.

There's (apparently) no way to get MC to show me a list of these tracks with "imperfect case" so that I can fix them.

Unfortunately, I don't think your suggested search would really work, if it is really looking at the file tags.  I don't KNOW which files are messed up, and I have a library of well over 40k files that might end up on my phone randomly.  I was hoping to make a View where it would always be populated, and I could periodically go in and fix them.  If that's looking at the file tags (which who knows if they're all perfect or not, I only care about the MC Library), then it would be slow and prone to errors.  I might try it, but I don't know...

Is there any way to run that same search on the MC Library tags rather than the file tags?

[MusicHawk]

MC is case-sensitive in at least one situation that might help you: the Tag window.

In a view, when two or more tracks are selected. if a given field (such as Name) exactly matches, the Tag window shows that text. However, if any capitalization is different, even if the text is otherwise identical, the Tag window shows [Varies]. Selecting tracks with a mix of Artist "Santana" and "santana" results in "Varies".

This might not be intended MC behavior, but it sometimes is a useful way to spot capitalization differences when several tracks *should* have the same text -- Name, Artist, Keywords, or whatever.

The fundamental factor is that Apple based its OS variations on Unix which is case-sensitive, unlike Windows which is not. It's not a bug or anything Apple is likely to fix, it's that the OS treats every character as the unique value it really is, not as equivalent to some other character, such as lowercase/uppercase which are entirely separate entities at the byte level. In fact, any of these would be different filenames to a case-sensitive OS: Santana, santana, sanTana, santanA, SaNaTaNa, etc, so they could all exist simultaneously in the same folder. Yet all would be identical to Windows so only one could exist (which Windows would try to show as Santana).

This is how virtually all computer systems EXCEPT Windows behave, which can create havoc when files move between Windows and other platforms. For example, most web servers are case-sensitive (Unix, Linux, Solaris, etc), so developers must take great care -- and usually solve the problem by forcing everything that is or might be used as a filename to lowercase.

Of course, applications often invoke case-insensitivity when sorting to be more user-friendly, as MC does, but they can't change the behavior of the file system.

Sometime back I posted about this (in response to some question or other), because I was storing files on a mix of Windows and Linux systems. My solution is to always force MC paths and filenames to be lowercase. In the actual database, I use normal case. So what shows in the tag as "Santana" results in a filename with "santana"; etc. By doing this I don't end up with multiple capitalization variations of the same file, so I haven't encountered the iPod problem.

Which raises a key question: Does the particular problem Glynor is encountering arise from capitalization of the physical file name, or the capitalization of embedded Tags?

[gappie]

Is there any way to run that same search on the MC Library tags rather than the file tags?

ah, ok i understand, dont try what i suggested then it wont help
have an other idea that could work for at least a big part of the files.
it uses three smartlists.
the first has as a rule

Code: [Select]

[Media Type]=[Audio] [=IsEqual(FixCase([artist],1),[artist],0)]=0 ~limit=-1,1,[artist]it uses a fixcase setting to the artist and compares it to the original name and when they dont compare they are in this list. and only takes one file from such an artist.
now a smartlist that does the contrary:

Code: [Select]

[Media Type]=[Audio] [=IsEqual(FixCase([artist],1),[artist],0)]=1 ~limit=-1,1,[artist]
the third smartlist uses these two smartlists and looks for duplicates of artist (works because mc is not case sensitive) and could be extended to full album
like:

Code: [Select]

[Media Type]=[Audio] playlistid==80827665,=40278139 ~dup=[Artist] ~a(the playlists id schould be changed ofcourse, those are mine )

it was all i could think of. maybe it helps a bit..
 
gab

[glynor]

MC is case-sensitive in at least one situation that might help you: the Tag window.

In a view, when two or more tracks are selected. if a given field (such as Name) exactly matches, the Tag window shows that text. However, if any capitalization is different, even if the text is otherwise identical, the Tag window shows [Varies]. Selecting tracks with a mix of Artist "Santana" and "santana" results in "Varies".

I know.  That's what gave me "hope" that there was a way to do it in a list-format.  Using the Tag AW is not an realistic way to browse the library and search for mismatches when you have hundreds and hundreds of artists and thousands of album titles to root through.

[glynor]

The fundamental factor is that Apple based its OS variations on Unix which is case-sensitive, unlike Windows which is not. It's not a bug or anything Apple is likely to fix, it's that the OS treats every character as the unique value it really is, not as equivalent to some other character, such as lowercase/uppercase which are entirely separate entities at the byte level.

Sorry, this argument (the same as one I've seen on many of the hundreds of threads about this issue on the Apple Discussion Forums), is completely irrelevant.  The HFS+ disk formatting system certainly can be case sensitive, but the DEFAULT behavior of OSX is NOT case sensitive.  A regular vanilla OSX install is just as case insensitive as Windows.  Besides, iTunes is NOT case sensitive, even on OSX with a case sensitive file system.  Just because the OS distinguishes between case in the file system, does not mean that the iPod app on the iPhone has to when displaying the file tags.  The iPod app doesn't care if the files are named "1.mp3".  These are two very different things.

In what circumstance would a rational consumer want "Death Cab For Cutie" and "Death Cab for Cutie" displayed as two separate artists?  There aren't any.  It is just lazy programming is all.  And poor UI design, which is surprising for a company that went to great lengths to make 00002 sort after 1 in their OS a long, long, long time ago.

Update: Actually, when you enable case sensitivity on a mac partition, it isn't officially called HFS+ anymore.  The Case Sensitive version is called HFSX, but the UI calls it a HFS+ Case Sensitive Partition.

[glynor]

it was all i could think of. maybe it helps a bit..
 
gab

Thanks, gab!  I'll take a look later tonight or tomorrow.  I'll probably just end up doing it the brute force way I discussed in the OP.

[MusicHawk]

I have no clue why Apple uses raw characters in some but not all contexts (my only Apple product is iPod).

I'm not making an argument, since I don't use OSX and have no concern about how it behaves. The point that case-sensitivity is "normal" in that every character is a naturally different value, so overriding this is an explicit decision with consequences. Case was overridden by Microsoft for Windows, which generated much criticism and to this day lots of hassles for heterogeneous OS/data environments. It's the reason mailing lists and BIG databases often have everything in all-caps, using just the "original" ASCII characters that exist on every platform. Lots of programming languages are case-sensitive, in commands and/or variables ("FirstName" and "Firstname" not being the same thing), so developers often use all-caps or all-lowercase to avoid creating obscure bugs.

Database users are sometimes spared the case challenge because many apps are intentionally case-insensitive,  while others make this optional. Of course, to appear to be case/accent-insensitive requires an OS or programming language or database to have an internal equivalency table, therefore to make decisions about what different characters to treat as identical. A = a might be an easy choice, but what about these same letters with the several accents used in various languages? Who's in charge of deciding that an umlaut doesn't matter?

Accent-sensitivity is important to handle text that might arise in German, Swedish, Spanish, French, etc, etc -- either ignore the accents, which might lead to bad data, or treat them as distinct characters but with side-effects. The problem of "For" and "for" being different might be a by-product of being accent-sensitive, which often requires being case-sensitive too -- treating every character as unique.

This can be handled at the app level, if allowed. For instance, IBM goes to great lengths to support almost every written language around the world. IBM Lotus Notes allows both case- and accent- sensitivity to be separately enabled per database, per view, etc. They have carefully tuned the equivalency tables that get turned on/off by these options, and documented what = what.

Other than the behavior of the Tags window, MC seems to be case-insensitive, though possibly accent-sensitive -- a design decision that was probably debated, so maybe Matt will explain.  Apple made a different decision, perhaps because of the world-wide market and many languages they encounter. If there are MC users on this board who deal with non-English accented Roman characters, perhaps they can say how MC behaves.

It's just a complex situation with no simple "one size fits all" solution. Simply ignoring case and accents can lead to a mess unless the environment is totally controllable.

As I said, I force MC to write all filenames as lowercase, but on the database/tag side, it's a work in progress. My main library is 60K+ records, and it's an ongoing project to locate and fix variations in Name, Artist, etc.

[glynor]

I understand all of that.  I'm just saying that it doesn't make sense in this particular context.  And you argued that OSX is case sensitive because of it's BSD roots, and that isn't true.  OSX is NOT case sensitive in basically every install out there.  To get it to be case sensitive, you have to wipe your existing install, boot to an optical disk, repartition the boot partition, and then reinstall OSX from scratch.  In fact, when you do so, loads of applications stop working properly (including Adobe Creative Suite).  It is a very niche case.  Aside from a handful of UNIX nerds, this just doesn't happen in the real world.

Besides, we're not talking about filenames, we're talking about metadata tags in a music player application.  And, yes, I would suggest that the vast majority of users across the world would prefer that accents also be ignored when sorting metadata tags into "groups".  I'm not talking about dropping the information, just not using it for sorting purposes.  There's a distinct difference.  I would guess that most regular people, even those in Iceland, would prefer "Björk" to sort with "Bjork".  Even though the latter is not technically correct, you don't want it to sort as a separate artist.  They obviously aren't two different singers!

And, again... I strongly doubt that this was a conscious "design decision" by Apple, since they made the exact opposite decision in iTunes.  If you know anything about their corporate culture (and I do) that isn't how they work at all.  It is a bug.  It is something they've ignored for a long time, which bothers some people and others just ignore.

[MrC]

have an other idea that could work for at least a big part of the files.
it uses three smartlists.
the first has as a rule

Code: [Select]

[Media Type]=[Audio] [=IsEqual(FixCase([artist],1),[artist],0)]=0 ~limit=-1,1,[artist]it uses a fixcase setting to the artist and compares it to the original name and when they dont compare they are in this list. and only takes one file from such an artist.
now a smartlist that does the contrary:

Code: [Select]

[Media Type]=[Audio] [=IsEqual(FixCase([artist],1),[artist],0)]=1 ~limit=-1,1,[artist]
the third smartlist uses these two smartlists and looks for duplicates of artist (works because mc is not case sensitive) and could be extended to full album
like:

Code: [Select]

[Media Type]=[Audio] playlistid==80827665,=40278139 ~dup=[Artist] ~a(the playlists id schould be changed ofcourse, those are mine )

it was all i could think of. maybe it helps a bit..

This was very useful, thanks!  I also created one for replacing Album for Artist to catch my inconsistent Album names too.  Combined, they seem to work well.