beaTunes News

This update fixes a couple of issues that became apparent after the release of macOS 10.15 as well as a few general things. It's recommended for everybody using beaTunes v5.2.0.

As always, you can download the new version from the download section of the website.

Changes in 5.2.1

• Re-added support for macOS 10.11.6 (was mistakenly disabled).
• Fixed play/pause triggered by entering SPACE in genre field (Windows only).
• Fixed very small application icon (Windows only).
• Fixed analysis queue processing hang after SocketException.
• Reduced memory footprint during iTunes/Music.app-based analysis.
• Improved startup performance for macOS 10.15.
• Improved handling of case-sensitive metadata file tags (esp. ReplayGain).

Labels: Catalina, Music, ReplayGain

Pretty much since forever, beaTunes is capable of synchronizing with either a folder-based or an iTunes/Music.app-based music collection. In both cases beaTunes synchronizes its database with what is found either in music files or the iTunes/Music-database—like a smart import (changes originating from beaTunes, on the other hand, are typically written right away). You can imagine that importing whole libraries takes a very long time, especially when they reside on an external or network drive (not recommended). Therefore beaTunes employs some tricks to speed up the process. For the old iTunes XML files, for example, it does a smart diff, not unlike the Unix tool diff. Thus beaTunes is able to detect changes and only import the relevant parts. For folder-based libraries, beaTunes simply looks at the last modification dates of your audio files. If the file has been changed recently, its metadata is re-read.

Now, with macOS 10.15 and the new Music app, doing a diff is not an option anymore and checking the file system is inefficient. Therefore beaTunes uses a last-modification/hash-based approach, which works really well. It has only one downside: Apple hasn't updated the ITLibrary framework for years. This is the Apple API that must be used to access the Music library. You simply won't find newer properties like loved, movement, or work. This means that just using the recommended Apple API certain changes cannot be detected. However, those properties are available via AppleScript (Apple did a better job here). And this is where forcing synchronization comes into play. When you manually initiate synchronization via the File menu, and beaTunes 5.2 cannot detect any changes, you are given the option to force synchronization (see screenshot), i.e., to ignore any shortcuts, previous knowledge etc., and re-read all available data. This makes sure that all your play counts, loved flags, etc. reflect the status in the Music app. As you can imagine, the process takes a little longer, so you might not want to do this all the time, but only every now and then.

Labels: Catalina, iTunes, Music, TipsAndTricks

For certain features like acoustic duplicate detection or lookup of metadata for files with no metadata whatsoever, audio fingerprints are a great feature. However, when you've fixed all your metadata and are not hunting for duplicates, they take up a lot of space in beaTunes' internal database. That's why beaTunes 5.2.0 introduced a new feature that I believe is very handy, if you have a large library. It allows you to quickly delete all fingerprints from the database, which can substantially shrink the database file. Why is this a good thing? The more the database grows, the more disk I/O may happen, and the slower everything becomes. So if beaTunes feels sluggish, you have a large library, and you don't need those fingerprints anymore—just get rid of them, by opening the Tools menu and choosing Delete Fingerprints. This will delete all fingerprints currently in your internal beaTunes database. Note that for this to take full effect, you will need to restart beaTunes, as database compression always happens on shutdown. Depending on the size of your database, it might even be beneficial to restart beaTunes a couple of times.

Labels: TipsAndTricks

With the pending release of macOS 10.15 (Catalina), Apple will get rid of iTunes as we know it and replace it with the new Music.app. Because some essential things have changed, beaTunes 5.1 or earlier will not work with the Music.app. The good news is, owners of a beaTunes v5.x license can update to v5.2 for free and v5.2 does support Music.app.

Undoubtedly, Music.app support is v5.2's most important feature. But there are some other changes, mostly small enhancements and bug fixes (see below). And this:

Important: Please note that due to Apple's notarization requirements I was forced to drop support for older versions of macOS. If you are using a Mac, you need at least OS X 10.12 to run beaTunes 5.2 (OS X 10.11 will be supported again in 5.2.1).

As always, you can download the new version from the download section of the website.

Changes in 5.2.0

• Removed some annoying tooltips.
• Reduced database size.
• Added ability to delete fingerprints from database (to reduce size).
• Added support for macOS 10.15 (Catalina) Music.app.
• Added support for Beatport during metadata import.
• Added ability to force synchronization.
• Changed keyboard shortcut for zero rating (Windows only).
• Updated built-in Discogs database.
• Dropped support for old macOS versions, because of notarization.
• Fixed love/dislike propagation to iTunes (macOS only).

Update

Due to a mistake, v5.2.0 requires macOS 10.12 or later. macOS 10.11 will be supported again in v5.2.1.

Labels: Catalina, Discogs, Java11, Release

If you're already using Catalina/macOS 10.15, please update to the latest snapshot. It addresses a couple of issues.

Currently there are no known issues. But keep in mind that you cannot simply go back to v5.1.x, because the internal database will be changed the first time you run v5.2.x. So, if your database is valuable to you, please keep a backup!

Here are the two links:

• macOS: beaTunes-5-2-0-SNAPSHOT.dmg
• 64-bit Windows: beaTunes-5-2-0-SNAPSHOT-x64.exe

Please report feedback in the forum.

Thank you!

Labels: Catalina, Java11

Good news! Notarization turned out not to be as difficult as previously thought. But it required more internal changes to beaTunes than anticipated. Obviously, that's a good reason to post another snapshot that contains these changes. And because they are not just about packaging, but the bundled Java runtime, the Windows version is affected as well. In essence, I had to move from Java 8 to Java 11. One of the consequences is that using macOS 10.11 or later is now recommended.

Please give this new snapshot a shot (ha! please excuse the pun), if you're on macOS 10.15/Catalina or Windows and feel adventurous.

Currently there are no known issues. But keep in mind that you cannot simply go back to v5.1.x, because the internal database will be changed the first time you run v5.2.x. So, if your database is valuable to you, please keep a backup!

Here are the two links:

• macOS: beaTunes-5-2-0-SNAPSHOT.dmg
• 64-bit Windows: beaTunes-5-2-0-SNAPSHOT-x64.exe

Please report feedback in the forum.

Thank you!

Labels: Catalina, Java11

Catalina will be upon us this Fall, which means that iTunes will be no more (R.I.P.). But that's not the only thing that will change. According to Apple:

Mac apps, installer packages, and kernel extensions that are signed with Developer ID must also be notarized by Apple in order to run on macOS Catalina.

This has a number of consequences.

First of all, this may increase security for users. A notarized app may be less able to carry out an attack. And users will be able to distinguish between notarized and unnotarized apps. If I am not mistaken, it might also give Apple a kill switch on any such app, at least when you first try to run it. Because as it turns out, macOS 10.14 and later phone home when first running a notarized app. Additionally, this gives Apple unique data about which software was installed on which IP address at what time. So for the user there are some privacy concerns and maybe some security benefits.

What does it mean for developers?

Frank Reiff recently wrote a lengthy post about all the trouble he faced when trying to notarize an app. It took him 5 days to get it all to work. In the end he concludes:

As a long time Mac developer (since 1994), however, I can’t help thinking though that the security people at Apple would have done better ironing out the bugs and limitations of the sandbox to get it work properly and be less of a nuisance, rather than adding yet another security approach.

If early reports about Catalina are to be believed, it looks like there are so many people working on Mac security that they have to roll out new security features at each release, whether they are a net benefit to users or not. Perhaps, these people could be tasked with making macOS great again instead?

AFAIK, Frank is using XCode and ships native apps. For beaTunes things are a little different, as it uses Java as runtime. So far Oracle (or anybody else I know of) has not shipped a Java runtime that has been compiled against macOS SDK 10.9 or later and the hardened macOS runtime. Additionally, Oracle's Java executables are not signed with suitable signature algorithms (see Bug JDK-8223671 for a detailed list of notarization failures). All these are requirements for notarization. There is no way for me to ship a notarized version of beaTunes before they are addressed and unless I want to roll my own version of Java (I don't!!), I simply have to wait and hope that someone at Oracle will take pity on Mac devs.

Not a pleasant situation to be in.

Update 8/6/2019

It turns out that notarizing a Java app that bundles Java 11 is a bit painful, but absolutely possible.

Labels: Apple, Java8, Notarization