Doug’s AppleScripts for iTunes has released Dupin v1.1.4, the iTunes duplicates manager. Dupin is an application that assists with locating, sorting, filtering, and deleting duplicate tracks in iTunes.
See Dupin in action. Watch the Dupin video tutorial presented by ScreenCastsOnline.
Updated in version 1.1.4:
- Changed keyboard equivalent for “Delete” function to Command-Delete, added “Delete Selected from Dupin” menu command
- Added “Sort by Dupe Groups” toolbar button
- Redressed issues with AAC files encoded using ABR
- Fixed problem with moving files from striped RAID to Trash
- Fixed rare problem with listing playlists
- Fixed rare problem causing inaccuracies when filtering by “Volume”
- Fixed rare problem causing inaccuracies when filtering by “Shortest Filename”
- Minor performance enhancements
This update is free for registered users.
With Dupin you can:
- Quickly find all sets of duplicate iTunes tracks based on your choice of criteria
- Select the “Keeper” tracks from among a number of duplicates automatically using a variety of versatile filtering options
- Purge duplicate tracks from iTunes and send files to the Trash
- Manage intentionally duplicated tracks
- Copy tracks to new iTunes playlists
- View duplicates in non-loaded libraries created with iTunes’ multiple library feature
- View duplicates in iTunes libraries on other machines on your local network
- Sort tracks and view track info
- Export a list of duplicates to a text file
- Locate tracks in the Finder and in iTunes
- Audition tracks
In addition, Dupin features:
- Familiar iTunes-like interface
- Robust Help
- Ample keyboard shortcuts
- Visual progress feedback during operations
- Customizable toolbars
- Optional update checking
I invite regular visitors of this site to have a look at the descriptions for this app and see if they are not virtually identical to many of the scripts I offer here. I gave the developer of this app permission to use one single snippet of code in one script of mine. Do you think that they over-extended my generosity?
I mentioned yesterday about the High ASCII bug in iTunes that prevents Chapter titles containing High ASCII characters from displaying in the Chapters menu of iTunes 7.5 (note that I still have yet to get a real confirmation on this). As far as Join Together is concerned, you can avoid the error caused by High ASCII in track titles by eliminating those kinds of characters in the track names in the Join Together Track List. As I mentioned yesterday, I have a fix for the error in Join Together, but because of the alleged iTunes bug, you won’t have access to those titles in iTunes 7.5.
I have gotten a couple of reports from users of Join Together regarding an error that occurs right when chapterizing begins. Turns out that ChapterTool was choking on High ASCII characters in the track names (?, ?, ?, ?, and so on). This error only occurs in Leopard, and I have fixed the problem. But I am hesitant to release an update just yet because it turns out that iTunes 7.5 willl not display titles containing High ASCII in the Chapters menu. At least not at my house. QuickTime will display the chapter titles, and iTunes 7.4.1 in Tiger will, but not iTunes 7.5 in Leopard.
I’d like to try to nail this down. Unfortunately, I don’t have any joined files created in Tiger that have High ASCII characters in the chapter titles. What I need to know is if joined files created in Tiger display their titles correctly in iTunes in Leopard. If you can be of assistance, please email me.
OK, so we know that unchecking AAC VBR in Preferences > Advanced > Importing actually gives you ABR (Average Bit Rate) encoding and checking it gives you VBR_Constrained. I just put up a script that uses afconvert to import CD tracks as old-style CBR (Constant Bit Rate). However, even this apparently does not provide a constant bit rate. For example, after ripping a few tracks with it and attempting to join and export them in QuickTime, I do not get the pass through option. Checking their info with the QT Inspector the bit rates are indeed slightly different. Here’s what’s weird: CD tracks I ripped with a pre-v7.5 iTunes without VBR also have slightly different bit rates, but QT allows the export as pass through. I’ve gotta do some research.
Now that iTunes doesn’t rip or convert AACs using constant bit rates (see this MacFixIt article), users of Join Together can’t take advantage of the Pass-through option, which encodes the final joined file much faster. Rip AAC Old School is an AppleScript wrapper for the command line tool afconvert. It will rip CD tracks as AAC using Constant Bit Rate (CBR) so that ripped tracks will all have the same bit rate. I tested it pretty thoroughly here, but I’m still keeping my fingers crossed.
According to this article at MacFixIt, “it now appears that this [is} neither a bug in QuickTime nor a bug in iTunes; in fact, it’s not a bug. What’s happened is that the meaning of the choices you make in iTunes has changed (without, as usual, any explanation or notice from Apple).” For more, read the entire article.
This thread and this thread at Apple Support Discussions describes a bug in QuickTime 7.3 which ignores your iTunes VBR (variable bit rate) settings for importing or converting AAC tracks. As a result, you always get VBR. (Thanks to Correspondent Christian who pointed this out to me when describing a problem with the “Pass-Through” setting of Join Together. This option will only be available if your selected tracks all have the same bit and sample rate. Of course, if they are VBR, they won’t all have the same bit rate and Pass-Through won’t be available.)
I smell iTunes 7.5.1 and/or QuickTime 7.3.1 coming soon. At least, I hope that’s what I smell.
I’ve updated Dupin to version v1.1.3. There apparently is a bug in Leopard that affects German and Dutch systems, and maybe others, which causes some time and date conversion errors (specifically, conversion of date strings that contain the abbreviation for the month of March/M?rz/maart). This latest version of Dupin works around the March Bug and, thus, prevents a sorting error on systems affected by it.
Finally got the script search form at the top of every page working properly again–well, pretty much. Because of some MySQL problems about a month or so ago, I neglected to update the search code and only recently figured out the problem. If You Wanna Know: the script search is a (simple) FULLTEXT search on the database using IN BOOLEAN MODE.