Closed Sleek1 closed 8 years ago
Would mangling the album name be your preferred work around, or what would be best in your view? Will consider it next time I'm in the code.
What would be best in my view would be what the Doug's Script does i.e. re-number the tracks to include the disk number. My reason is that I prefer an "album" to be by itself when sorting or viewing by album. I have some album collections that have 19 discs (Haydn String Quartets)! For every album that has multiple discs, you see multiple albums for that one album if you added "(Disc X)" to the name of each album. If that is easier to program, it's not really a big deal. Imagine what I see now when I pull up that Haydn Quartet Album...19 track 1's, 19 track 2's etc. Thank you of considering this.
I would like to add that I am using the following work around for the Disk Number sorting problem.
I know this seems like a lot, but it allows me to keep my iTunes library "clean" and will be much easier now that I have a workflow. It would be next to impossible without TeslaTunes! Thank you again.
I was rebuilding the app due to a Sparkle/Apple security issue that was recently announced and thought I'd look at this while I was still in the mode of looking at the project. I started adding the embed disc number in track number approach as yet another tag twiddling toggle (tm) :-) but then I saw your comment on step 4 above. Not running it on track 1s seems odd to me.
I could see not running it on single volume sets - though that assumes I can trust/figure out from the tags how many volumes are actually in a set.
I could see remapping the track numbers differently than the applescript does. Instead of
new track number = disc number*100 + old track number
it could be
new track number = (disc number - 1)*100 + old track number
So that track numbers wouldn't change for disc one, disc two would have track numbers like 101, 102, etc., and everything would still sort properly.
But fundamentally, I'm trying to understand what you are really getting out of the extra step of "You don't run it on the '1 of x' because they don't sort…" step. Seems like whichever way you map or don't map, if you look at all tracks, you'll have things mixed, whether there's a bunch of track 1s, or track 101s, etc. Can you try again at explaining why this step matters?
In answer to your question, the main reason I didn't covert all disk 1's is because of the time it took with the script and my collection of 50,000 songs! The script does not give feedback and basically locks up iTunes while it is working for hours. Since the majority of my collection is disk 1 of 1's that was a waste of time. I agree with you logic above i.e. it is probably better to convert everything that has a disk number.
iTunes does not sort the disk numbers disks in list view properly because it ignores the "of X disks". It doesn't have all the 1 of 1 disks together in the list if you sort by disk number, so if you want to avoid changing the disk 1 of 1's, you have to manually select the 1 of 2's and 1 of 3's etc and skip the 1 of 1's. Now on the Tesla, it doesn't really matter if you convert all of the disk 1 of 1's or not because if you don't, and there is more than 1 disk, it still sorts properly on the Tesla interface.
Pertaining to your suggestion above, If you use new track number = disc number_100 + old track number the first number of the track is equal to the disk number. That way, if you are playing a song which is track 1 from disk 5, the track number will be 501, making easy to tell the disk number, as you suggest. If you use new track number = (disc number - 1)_100 + old track number then you have to remember to add 1 to the first number to get the disk number. Either way works and I agree, I like the first way better. The first one does more track number changing (since it changes EVERY track that has a disk number) but basically substitutes the disk number for the first number in the track keeping the tags logical. The other way (disk number -1) doesn't touch the majority of the collection since probably 80-90% of all tracks are a disk 1 of 1. The down side is the first track number will not match the disk number tag and may confuse people.
I'm worried what would happen if you run TeslaTunes with the new track number changer option selected a SECOND time? Lets say you didn't finish the conversion all the way through, or you did but you want to run it again because you updated your library. When I accidentally ran the iTunes script the second time it really messed up the track numbers i.e. track 1 on disk 2 initially converted to track 201. The second run it becomes track 2*100 + 201 = 401. Just something to think about. I guess if TeslaTunes is converting the 2nd time, it is converting off of the original, unchanged iTunes files so this probably doesn't matter. It will matter if you try turning the option on, then off. You would probably double up your collection.
I went ahead and made a version 1.2.3 release and zip file. I haven't turned on autoupdate for it yet because I'd like you to try it out and see if it works properly as well as adequately addresses your request. Though the issue got marked closed automatically as part of the update, I'll reopen if needed based on your feedback.
I can't wait to try it and you are unbelievable! I'm at work now but will post here as soon as I get home in about 6 hours or so. Unless you work nights, I'm sure you will be sleeping...
Either you added a section to your comment right before the close comment, or I just really wasn't observant. So here's my response to some of the things you brought up in the section I missed.
I ended up skipping the embedding on all disk ones. I didn't think of doing this originally, it was your idea in your response to my couple of suggestions. I gave you choice A or B and you chose C :grinning: Turns out that was a good suggestion so I went with it.
I was going to check the number of discs tag and only do the embed for tracks that were part of a multi disc set, but I worried about that tag being reliable (still do), which led me to propose the disc number - 1 numbering for the hundreds place. I guess initially the gap between having 1,2,3… 201,202,203.. etc. with not having the 101,102… bothered me, but after you suggested it and it didn't seem to bother you, and since not everyone buys into counting things starting with 0 instead of 1, the idea grew on me.
As for what happens if you run TeslaTunes again with the option selected, as you surmised it's fine since it never changes your library.
As far as changing the option and running again, you won't get multiple copies, but it won't rewrite the files that are already there to reflect the updated options.
The decision to copy/convert or not is very straightforward, aka dumb. It simply figures out what the filename will be for the new file, then looks and sees if it's already there in the destination. If not, it goes ahead and does the operation. If it is, it doesn't do it, regardless of whether the source file has changed since the last run, whether the options changed, etc.
If you decide you want different options selected and need to replace files that are already on the destination with new files with the new options, you'll have to delete the old destination files yourself. You can do that individually or just delete the whole destination folder, or anywhere in between as you wish, trading off the time to rerun the app vs. your time hassling with the individual deletions. I tend to blow it all away and just rerun :stuck_out_tongue_winking_eye: For the Playlist section, the app will delete old files and playlists that are no longer referenced from your currently selected playlists, but that's the only time the app will remove/update files that are already on the destination. I figure you'll figure out the combo of options you want pretty fast, then never change them again, and if you do you'll just remake the whole destination.
No, you are very observant. I posted a comment but then went back and edited it, hence the change.
I ran TeslaTunes on my Library and it is working perfectly. It does pretty much exactly what I was doing manually. Wow. I even saw another advantage of not renaming the 1,2,3's to 101,102,103's... The Tesla interface chops part of first number when listing a track number in the hundreds. If the entire collection were this way it could be annoying but since disk 1 numbering doesn't change it works well as most albums are single disk.
Thanks again. I'll try a complete redo on my entire collection this weekend and let you know how it goes.
Great to hear. Will let it sit for the weekend, and if all seems well will bundle a new release for the autoupdate after that.
Well, I ran it on the entire iTunes library and it seems to be working as described. No issues noticed and hasn't crashed.
My ONLY nagging problem with using my iTunes collection (after the help of TeslaTunes) is that the Model S does not recognize the Disc # tag used in iTunes. If an album contains more than one disc, you end up with the tracks merging and the Tesla playing starting with track 1 from one disc then track 1 from the other disk (not even sure the order). I know I could fix this problem by using Doug's Script "Embed Disc Number in Track Number v1.0" which would rename the track numbers to 3 digits so Tesla understands. I could also rename the album and separate into "Album name (Disc 1)" and "Album Name (Disc 2)" etc. I could also simply not restart track numbers with every disk and continue the count for all disks (2 disks with 10 songs each would end with track 20 of 20 instead of Disc 2 10 of 10). I prefer keeping my iTunes library clean without these undoable changes. Would be nice for TeslaTunes to have an option for "renumber multiple disc albums." My work around now is just to copy my entire 2TB iTunes collection, run "Embed Disc Number in Track Number" script and run TeslaTunes from the updated iTunes folder and delete when complete. Thank you for considering this.