After explaining the overall idea, how libraries work, and the finer details of analysis options, today I am going to talk about inspection.
As you might recall, the main idea of inspection is to improve your textual metadata. Inspection does not magically tag all your files correctly (there is an analysis task that can help with that, though). Instead, it supports you in identifying potential issues like spelling mistakes and offers appropriate solutions. Let's look at this step-by-step.
Before you run an inspection, you might want to synchronize the beaTunes library with iTunes or your music files, so that the internal beaTunes database is up to date. You can do so via the File menu. Then click on the inspection button in the toolbar, the Tools menu, or simply use the keyboard shortcut Shift-Command-I. beaTunes will scan your library for issues. How long this takes depends mostly on the size of your library and which inspectors you have enabled (fewer = faster). Once the initial scan is complete, beaTunes will display the found issues along with suggested solutions.
Then the procedure is as follows:
- Select one or more issues
- Only if you selected a single issue: Select the songs you want to apply a solution to
- Choose the solution and apply it
- Move on to the next issue
Note, that when you select more than one issue at once, not all displayed solutions will necessarily be appropriate for all selected issues—however, they will only be applied to appropriate issues.
Whenever you apply a solution, beaTunes displays two dialogs. The first dialog makes you aware of the fact that the actual change has not happened yet. Instead, the chosen solution has been added to the list of pending solutions. This list appears at the bottom of the inspector list. It allows you to review all applied solutions before you actually commit them. More about that in a bit.
The second dialog asks, whether the issue at hand has been completely resolved. If your answer is Yes, beaTunes removes the issue from the open issues list. If it is No, the issue stays and you can apply another solution to the same issue. This makes sense, e.g. when an issue lists five songs as having the same rarely used genre. Upon checking the songs out, you might realize that the first two belong to pop, while the other three belong to jazz. So you first select the pop songs, apply a solution that changes their genre to pop, and then select the jazz songs and change their genre to jazz.
As mentioned above, applied solutions aren't immediately committed. Instead, they are collected in the pending solutions list where they can be reviewed, dropped, and committed. To do any of these things, select the Pending Solutions item in the left pane of the application window. Once you see the list of pending solutions, you can either commit them or delete them—either in bulk or individually via the context menu.
If you dislike this two-step approach of applying and committing—well, you can turn it off. The corresponding switch is located in the inspection preferences and called Delay committing changes. You guessed it, in order to commit solutions right away, you must turn this option off. The same preference pane also lets you turn individual inspections on and off.
Even though the bulk of the offered inspections aim at consistency of textual data, one of the more popular inspections has nothing to do with metadata improvements. Finding and removing duplicates is a great pain in large collections and beaTunes has an inspection that can ease this pain. By default, beaTunes uses the existing textual metadata like song and artist names to find duplicates. Sometimes, songs already have identifiers like ISRCs embedded—those are used as well. Additionally, to identify duplicates that come with wrong or insufficient metadata, beaTunes can use acoustic fingerprints. Unfortunately, it can take quite a while to compute those, therefore they are not calculated during inspection. In order to take advantage of them, you must first analyze your library with the fingerprint analysis task turned on. Once that has happened, beaTunes will take them into account when you run the inspection.
This little guide hopefully explained in detail how inspection works. If you have further questions, please comment below or start a discussion in the support forum.
This article is part of a small series under the heading "HowDoesItAllWork".
- Part 1 explains the overarching idea behind beaTunes.
- Part 2 explains what kind of libraries beaTunes supports.
- Part 3 takes a closer look at analysis and analysis options.
- Part 5 concludes this little series, showing how to build great playlists.
Labels: HowDoesItAllWork, Inspection