Aqua Taskforce

migueld wrote on December 15, 2008, 9:47pm

Who is demoting this? Why does a CD album get imported by track # but an Amazon album by alphabet?

ebaur wrote on December 15, 2008, 10:50pm

Can you explain more why this is an issue? I'm not going to demote it, per se... but I'll be honest and say that i don't get why this is an issue.

iTunes allows you to sort your music by any number of aspects, including by track number. In fact, I think when you sort by Album name, it automatically sub-sorts by track.

So, what problem does this cause?

migueld wrote on December 15, 2008, 10:53pm

I sort by date added, but it doesn't sub-sort by track number. So CD albums show up in order, but other sources don't.

zog wrote on December 15, 2008, 11:52pm

Ahh, so really what you're after is sub-sorting. Just like "Album by Artist" and "Album by Year" are pre-packaged sub-sort combinations, you're looking for "Album by Date Imported" -- or that effect.

That clarifies the intent behind the original post a great deal.

Still, changing the system-level code that hands iTunes the list of files to import is far from the only way to solve this problem. Direct support in iTunes for the sorting criteria you're looking for (whether in an "Album by Date Imported" column or something else) would be simpler to implement and make more sense.

In the meantime, I'm sure an AppleScript would be capable of creating a playlist sorted in the manner you want. Maybe there's one out there already.

Otherwise, perhaps a Smart Playlist could at least give you some of the utility of what you're looking for. For example, I have Smart Playlists for "Imported in the Last Month", "Imported This Year", and so on.

Sorry if the community aspect of promotion/demotion is frustrating you, but I hope these suggestions are helpful.

migueld wrote on December 16, 2008, 12:32am

Thanks for the suggestion. Yes I'm currently using an Applescript to add other sources, but obviously it's not an ideal solution. Perhaps I should make a request to have an "Album by Date Imported" option.

polycat33 wrote on December 16, 2008, 1:08am

I definitely agree with the annoyance, however my annoyance is also with CD importing, because I sort by date added so the newest is at the top. When a CD is imported, it's first track is imported first, and last track last, which makes the order backwards in my sorting. And of course bringing in tracks from other places they are definitely out of order. However, I kinda look at it as a quirk due to the way I like to view my music, and I'm not sure that making it the way you suggest is most useful for everyone (as I assume that making it the way that I'd like wouldn't be useful for most people).

That might explain why some people are demoting - if your suggestion would cause an annoyance to them. That's what this website is all about, stating your annoyance and seeing if the majority of people agree or disagree (and then potentially having apple actually do something about it). I'm not going to vote either way because what you suggest would simply make everything imported into iTunes in backwards track order, which isn't much better than the way it is now for the way I view things.

migueld wrote on December 16, 2008, 3:46am

polycat33, I think you an I have the same usage and I understand the situation you describe where track # are inverted when importing from a CD. My workaround is to sort by date added so that newest is at the bottom instead of top. So importing CDs are always in order. It's not the ideal solution, but that's how I had it set up.

"That might explain why some people are demoting - if your suggestion would cause an annoyance to them. That's what this website is all about, stating your annoyance and seeing if the majority of people agree or disagree (and then potentially having apple actually do something about it)."

So far those that demoted this haven't given a reason of why it is beneficial to have added tracks out of order and that's why I asked. I just bought an album from the iTunes store, and look at the order, it's not even alphabetical it's just useless: http://img218.imageshack.us/img218/4956/picture1ck7.png

It seems that "Date Added" tries to add tracks alphabetically, but sometimes it shuffles tracks if one downloads faster than the other. Maybe one track gets downloaded 10 milliseconds faster, and so that gets added first. That seems pretty useless to me, I don't care if one track within the same album gets added 10 milliseconds before another.

"I'm not going to vote either way because what you suggest would simply make everything imported into iTunes in backwards track order, which isn't much better than the way it is now for the way I view things."

Fair enough. I have a suggestion. As one adds a new album to iTunes, have iTunes treat it as a unit, respecting track # order. Then, whether date added is set in ascending or descending order, track # would always remain in ascending order (1,2,3,4,5 etc) within each album.

ebaur wrote on December 16, 2008, 5:30am

Okay, I know this is a site for "annoyances" and that you have every right to be annoyed at the behavior, but I'm going to get on a soap box for a moment.

Expecting "Date added" to be anything except the date that track was added to the library is silly. Case in point: "It seems that 'Date Added' tries to add tracks alphabetically, but sometimes it shuffles tracks if one downloads faster than the other." It isn't *trying* to do anything here. iTunes is downloading / importing in some order, it may be alphabetical if off disk, for example, but the value of Date Added is only meant to mark when *that* track got imported into *that* library regardless of how it got there.

People here keep trying to ready way too much into this value. I work a lot with databases and I find that this type of date stamp is frequently misunderstood by people who want it to be more significant than it really is. "That seems pretty useless to me, I don't care if one track within the same album gets added 10 milliseconds before another," demonstrates this. This value is exactly what it says it is: nothing more, nothing less. There is nothing to fix or address with that value.

Now, I don't like to criticize without offering a solution... so, in my humble opinion, what you really want is a "Date Album Added" field. You are all talking about using the date order in lieu of a track ordering (which is effectively mixing data types). What you all seem to really want to do is order the songs by the albums most recently imported and then the normal track order within that group. The only way to do that - keeping the data meaningful - is to use a new property that accurately reflects what is going on, not try to hack an existing property to do something it wasn't intended to.

Okay, I'll get off my soap box now...

migueld wrote on December 16, 2008, 3:38pm

ebaur your comment is well taken and I appreciate your insight. I don't have a problem with a "Date Album Added", it sounds like a fine solution. I did mention this on one of my previous posts as "Album by Date Imported"

"Expecting "Date added" to be anything except the date that track was added to the library is silly."

Is it really? Semantically, what's being added, a track or an album? From the user's perspective an album is being added. The album is the unit, not a track. IE "at what time did you add the album?" The answer is one, not a dozen. Sure, from a technical perspective it's an array of audio files and each is being added in a sequence, one after the other. But the semantics don't necessarily need to match the underpinnings. IE if a thread returns 10 milliseconds before another, it may be silly to output such order. A developer may choose to output by alphabetical order instead.

Having said that, I guess what I'm proposing is that the "Date Added" property would be more usable if it was defined as being per album instead of per track. So suppose that's the case, then when one adds an album, all tracks would have the same date stamp. Would that make sense?

Either way, I'm fine with the other solution. I just think that the current "Date Added" is unusable in it's current implementation.

ebaur wrote on December 16, 2008, 5:39pm

"Semantically, what's being added, a track, or an album?"
A track.

"The album is the unit, not a track."
Nope. iTunes and the music store work hard to make a track the unit, not the album. I remember reading somewhere recently that the majority of the purchases from the store were single track purchases, not albums. When you add things to a play list, you do it by track, not by album.

In fact, I think it's a dying breed that listens to "albums" as it seems most people I talk to either have so much music that they only listen to the tracks they like best or have so little that they only buy singles.

An anecdote: I got a free download from Jem awhile back. Since I like the song, I bought the rest of the album about a month later. In my library, the song "They" has an older Date Added and if some one asked "at what time did you add the album" it wouldn't be a simple answer, would it?

My point here is don't change the meaning of a field that A) works just fine and B) means exactly what it says it means. If you want different information, ask for a new field, don't mangle the meaning of the old one.

"I just think that the current "Date Added" is unusable in it's current implementation."
Remember, just because you don't see a use for it doesn't make it useless. It may be useless to you, but try not to project that on others.

migueld wrote on December 16, 2008, 6:26pm

ebaur, I don't agree with your view, but I think we both presented our views thoroughly and any more discussion on the same subject would just be repetitive.

For what it's worth, I'll broaden my request to include the possibility of a "Date Album Added" new property which should be a fine solution to the issue. Thanks

migueld wrote on December 16, 2008, 6:54pm

The new request can be found here: http://www.aquataskforce.com/view/245

Thanks for the feedback, everyone.

zog wrote on December 16, 2008, 7:03pm

This discussion seems to highlight one of the pitfalls in how this community is set up: we're not just identifying problems, we're also proposing specific fixes to them. The former are easier to agree on than the latter.

I think we can all agree that the sorting quirk in the iTunes UI which migueld identified is, at the very least, a potentially annoying inflexibility in iTunes. That is, it would simply be nice, somehow, to be able to sort albums by the date they were added, but by track within the album.

But several of the mechanisms proposed so far are quite unpalatable to me, including adding a "date album added" metadata property. iTunes already has the "date added" metadata for each constituent song -- if you're looking for "date album added", all that remains is to use some aggregate function (min, max, first, last, average, whatever) to *infer* it from the constituent dates.

As I peruse Aqua Task Force, I can easily agree that most of the quirks identified are legitimate problems. But most of the solutions proposed would either cause another problem, or break UI consistency, or introduce needless complexity, or otherwise interfere with something about the Mac I like. Perhaps the original submitter didn't think of those side effects, or perhaps they simply don't agree that the side effects are undesirable. Regardless, I end up voting them down, as I did with this one.

I would be curious to see how much the voting results would change if the structure of the community were different -- if solutions were separated from problems.

People could submit quirks they notice, simply describing something as a problem, and then the community could vote on whether they agree to acknowledge the quirk as a problem. Then, for every quirk, people could submit potential solutions, which would have their own, separate voting structure.

As things stand right now, there's no way to tell if someone voted "no" because they don't see the problem or because they don't like the proposed solution. All we know is that "yes" means they agree it's a problem AND they agree with the proposed solution.

Perhaps that helps offer an explanation of why there are so many "no" votes that puzzle and frustrate the original submitter. Unfortunately, I think the submitters will simply have to live with it as long as the site stays structured the way it is, or unless their proposed solutions are obviously and indisputably an improvement to the status quo.