Hi all, here is the fre:ac development status update for January and February 2020. It's been two really busy months which is why I skipped posting an update for January. This leaves two beta updates, a 1.0.x service release and some interesting changes for the upcoming 1.1 release candidate to cover in this issue.

fre:ac 1.1 beta 2

fre:ac 1.1 beta 2 was released mid January and I already covered the most important changes in the December status update - fixes for SuperFast LAME encoding and support for accent colors on Windows 10.

The remaining changes for beta 2 are:

• Logs now contain total duration and speed of conversions
• Logs now list names of active DSP components
• Fixed inability to update ID3v2 and APEv2 tags in the tag editor
• Fixed inability to interact with topmost windows when a modal window is active
• Fixed random crashes at program launch and exit on Haiku

fre:ac 1.1 beta 3

The third beta release followed in mid February and brought some usability improvements and bug fixes. The most visible change likely is support for dark mode on Windows 10. fre:ac now adjusts its color scheme when the preferred application mode is set to dark in Windows 10's theme settings.

Other changes for Windows users include the installer now being code signed, meaning no more red warning screens when running it and no more "Unknown developer" warnings when requesting installation privileges. Also, the uninstaller is now reachable via the "Add/Remove Programs" feature, placing it where most users would expect to find it.

The update also introduced a DSP information field in the status area, stating whether DSP processing is enabled and if so, which filters are selected. This makes it immediately visible when e.g. speech processing filters like noise reduction are still active even though they should be off for music conversion.

Besides those, the beta 3 release fixed several issues:

• Fixed inability to decode FLAC files on macOS
• Fixed inability to open Opus files with an .ogg extension
• Fixed compatibility with Windows 10 UTF-8 codepage setting
• Fixed crash on some Linux distributions when clicking on edit fields
• Fixed drag and drop of Unicode file names on Haiku

freaccmd fixes and improvements

After some issues had been reported by users of the beta, I had a closer look at freaccmd again, resulting in some improvements and several fixes:

• Gracefully handle Ctrl+C to remove unfinished output files upon abort
• Chapters are now preserved when converting (and there's a new option to turn this off)
• Improved cover art handling (and added a new option to completely ignore cover images)
• Fixed support for output folders specified relative to the current directory
• More configuration settings are now set to default values when running freaccmd

These changes will be included with the upcoming 1.1 release candidate update.

Other improvements and fixes

In addition to the above, several other things have been improved or fixed since the beta 3 release:

• LAME encoder 32 bit float support
  When using the LAME MP3 encoder, fre:ac will now pass 32 bit float samples directly to it instead of first converting to 16 bit integer samples if the original data is 24 or 32 bit.

• Logs now list CDDB information
  When ripping CDs, the CDDB information acquired from freedb is now listed in the ripping log.

• Fixed drag & drop of long path names on Windows
  It's surprisingly difficult to correctly implement drag & drop of path names with more than 260 characters on Windows. fre:ac will finally be able to accept such paths via drag & drop starting with the next update.

• Improved color scheme on Windows Vista, 7 and 8
  fre:ac now uses the configured accent color for captions and highlights on older versions of Windows too, in addition to Windows 10.

• Improved HiDPI detection on Linux/FreeBSD
  High DPI screen detection on Linux and FreeBSD has been improved to make it work automatically in most cases, without requiring the GDK_SCALE environment variable or the --scale:n.n argument.

• Fixed fre:ac icon not showing up for the Snap version
  When using the Snap version of fre:ac on Linux, the icon did not show up in the launcher in most cases. This is now fixed in the edge channel and will be fixed for all users with the 1.1 RC update.

Build system improvements

Some changes have been made to improve the build system to make it easier to compile fre:ac on your own.

The improvements fix a longstanding issue that prevented building on Windows from a build directory with a too long path and allow using build paths that contain spaces on all systems.

Also, there are now packaging scripts for macOS in the packaging/macosx folder, making it easier for users to build their own fre:ac app bundles and DMG images.

fre:ac 1.0.33

Among all the beta updates, I also published a service release for the fre:ac 1.0.x branch in mid February. fre:ac 1.0.33 will be the final update in this series, as the 1.1 release is expected to be ready later this month.

The 1.0.33 version comes with codec updates, bug fixes and - like the 1.1 beta 3 update - a code signed installer.

freedb shutting down

The freedb database used by fre:ac to query CD information for ripping will be shut down on March 31st. Magix, who took over the project in 2006 and guaranteed continuation of the service, sadly made this annoucement without stating any reasons for the shutdown and unfortunately were unresponsive to inquiries and offers from the community to continue the service.

fre:ac is already prepared to continue working after the shutdown. The latest updates now point to freedb.freac.org which will be directed to an alternative freedb service after March 31st.

This will be temporary solution implemented until support for the alternative and very capable MusicBrainz service will be available in fre:ac.

That's it for this status update. We have an exciting month ahead, expecting a release candidate very soon and the final fre:ac 1.1 release at the end of the month. Be sure not to miss it!

Hi all, a bit late, but here's the fre:ac development status update for December 2019.

fre:ac 1.1 Beta 1

The biggest news of course is the release of fre:ac 1.1 Beta 1. This concludes several years of Alpha development and paves the way for a fre:ac 1.1 final release in spring.

Some notable improvements have made it into this first beta last minute:

• The Windows and macOS versions of fre:ac now support smooth scrolling with trackpads and free-spinning mouse wheels
• Case conversion functions have been improved to better handle brackets and apostrophes
• The duration and speed of file conversions are now written to the log files
• Interoperability issues with the Windows clipboard, causing inability to paste text in some cases, have been fixed
• When installed using the Windows installer package, fre:ac can now be uninstalled via an entry in the Add/Remove Programs list

After this release in mid December, development during the rest of the month was mostly fixing bugs reported by users of the beta version.

SuperFast LAME fixes

One user provided a file showing an audible glitch when converted to MP3 with LAME while SuperFast mode is enabled. This issue traced back to a bug in the smooth class library's IO subsystem, that was missing instructions for switching between read and write mode, causing writes to fail in some cases.

Additionally, during the analysis of this issue, some rarely triggered bugs with the MP3 bitstream repacker used with LAME in SuperFast mode have been identified. Fixing these makes the repacker more robust when encountering unusual situations in the bitstream.

These fixes will be included in a second beta release in the beginning of January.

Accent color support on Windows 10

The next beta release will also respect the accent color set in Windows 10's appearance properties and use it in places like the titlebar, highlighted list entries and as the background color for selected text.

Somewhat related, work is also gouing forward on adding support for dark mode on Windows 10. That, however, will be available in a third beta release in February, at the earliest.

Other fixes

Some other fixes will be available in the upcoming second beta:

• Fixed hangs and other odd behavior when removing a disc while ripping or adding its tracks to the joblist
• Fixed Vorbis ABR bitrate management options (the values for minimum and maximum bitrate were mixed up, causing a too low bitrate to be used in many cases)

That's it for this month's issue. Make sure to come back for the fre:ac 1.1 Beta 2 release in a few days and for a new development report in one month.

Hi all, unusually punctual, here is the November 2019 status update on fre:ac development. It has been an exciting month with lots of improvements and an important decision.

fre:ac 1.1 beta is coming

Feature development for fre:ac 1.1 has been completed. Yay! I currently plan a beta release for mid December (probably the 15th) and I'm currently preparing everything for that release.

Translators needed

Part of the preparations is to contact translators and ask for updates to existing translations. While many are already working on updating their translations for the beta, some were not reachable due to outdated mail adresses or are not available for doing translations any more.

This is where you can help! If you speak any of the languages marked as needing a new translator on this GitHub page or would like to contribute a completely new translation, please post a comment there or contact translations@freac.org to get involved with translating fre:ac. Any help is greatly appreciated!

I also set up a project on Crowdin, a community platform for collaboratively working on translations. Everybody can contribute translation updates or even just suggestions for improving individual translated strings there. So have a look at the fre:ac project page on Crowdin to see where you can help.

Logging support

Support for creating log files was the last feature planned but still missing for fre:ac 1.1. It has been completed and pushed to the code repository in mid November, paving the way for the upcoming beta release.

New versions of fre:ac will now create log files of conversions in a dedicated logging folder, keeping them for 30 days by default. You can also choose to have conversion logs stored with the resulting audio files and there is an option to do this only for CD ripping jobs.

The log files contain a header with some general system information like the operating system, processor and CD drive used, followed by a detailed log of all file actions during the conversion process as well as verification results if applicable.

Keyboard input fixes

Two issues with keyboard input have been fixed in the past weeks, affecting mostly users of non-English keyboard layouts. The first one being an issue writing accented characters (using a dead accent key followed by a character key) on Linux after switching the keyboard layout. In some cases it could happen that fre:ac omitted the accent in this situation and recorded only the plain character (so ´ + a would not result in á, but print just a).

The second issue affected keyboard layouts that use AltGr+A,C,V,X,Y or Z to write diacritic characters. A notable example is the Polish layout which uses AltGr+A for the ą character and AltGr+Z for ż. These key combinations led to executing the Select all and Undo commands respecively before writing the character on all systems except macOS (which uses an extra command key for performing clipboard actions).

Both issues have been fixed now.

Smaller changes and improvements

There have been some smaller changes and improvements last month as well:

• SuperFast mode enabled by default
  The SuperFast mode discussed in several posts here earlier now got enough testing to be enabled by default for the upcoming beta. This can speed up conversions to MP3, AAC, Opus and Speex significantly, especially when doing output to a single file or converting less files than your system has CPU cores.

• Support for 32 bit content in Monkey's Audio files
  The Monkey's Audio (APE) codec recently got updated to support 32 bit content (it was limited to 24 bit sample resolution before). fre:ac now recognizes this and allows encoding Monkey's Audio files with 32 bit resolution.

Bug fixes

Apart from the mentioned improvements, some bugs have been fixed too:

• Fixed drag & drop on macOS
  Drag & drop support on macOS has always been a bit unreliable with fre:ac. Fortunately, I now identified the reason and was able to fix it quickly. Unlike other OS', macOS does not send mouse position updates when in drag & drop mode. Because of this, fre:ac often had the wrong position for the drop action which in many cases lead to the action being ignored.

• Fixed conversion of long files with external decoders
  There was a bug with converting long running files that need an external decoder, such as AC-3. As soon as the internal decoded representation of such a file exceeded 4 GB, fre:ac would no longer show the file's duration nor any progress during conversion and pop up an error message at the end of the conversion process even though the file had been converted properly. This is all fixed now.

• Stability fixes for Haiku
  The Haiku operating system, unlike most other OS', has a multi-threaded UI system. This led to some instabilities when running fre:ac on Haiku due to missing synchronization between UI threads in a few places. The next release should fix this and run much more stable on Haiku.

The upcoming fre:ac 1.1 beta will ship with all these fixes.

Other notes

Two features already discussed in the August and May updates respectively have been committed to the code base now:

• Dark mode support for macOS
  This has taken escpecially long to finish as it required a total overhaul of fre:ac's macOS UI code as well as a new synchronization mechanism to avoid lock ups. The latter should improve stability on non-Apple systems too. Everything is done now, so you will be able to enjoy the upcoming fre:ac 1.1 beta in dark mode on macOS.

• Support for using the iTunes store app's AAC encoder
  This was already announced in May, but only pushed to the code base in November as finalizing dark mode support had a higher priority, but this feature needed some compatibility improvements in order to work on all computers.

That's it for this month's issue. Be sure to come back mid December for the fre:ac 1.1 beta and in January for the next development update.

Hi all, this is the fre:ac development status update covering the months of September and October 2019.

Several improvements have been implemented in these past two months along with some bug fixes. So let's have a look at the changes in detail.

RNNoise model selection

The RNNoise noise reduction code has received an update earlier this year that allows configuring the neural network with different noise reduction models. Several models are provided to accomodate different combinations of speech or general audio with ambient or recording noise.

The model to use in the DSP chain of a conversion is now configurable in fre:ac.

Tagging improvements

Several improvements related to tagging have been implemented in the past two months:

• Chapter support for APEv2 tags
  This brings chapter support to formats like Monkey's Audio (APE), TAK, WavPack and Musepack to enable single file album images that can later be split into individual tracks without the need for a separate cue sheet file.

• Recognize album art when loading cue sheets
  Album art is now recognized when loading tracks to the joblist using cue sheets.

• New tag fields
  In addition to the tag fields mentioned in the 08/2019 update, support for the Performer, Arranger, Producer and Engineer fields has been added.

• CD-Text support on macOS
  The macOS version of fre:ac is now able to read CD-Text information from discs that carry it (mostly Sony releases).

Bug fixes

• Improved drag & drop on macOS
  Drag & drop support on macOS has been a bit wonky up to now, which was found to be caused by mouse pointer updates not reaching the program in drag & drop mode. This is now fixed in the code base and will work much more reliably in upcoming releases.

• Fixes for gapless MP4 AAC
  When using MP4 AAC in non-LC mode (meaning e.g. HE or HEv2 AAC), decoding was not always gapless. This has been fixed to allow sample-exact decoding with any AAC mode.

• Fixed support for very long MP4 AAC files
  Very long AAC files with durations approaching 20 hours need 64 bit fields to store their duration internally. This was not really supported until now and is now implemented.

• Fixed crashes and hangs
  While working on everything mentioned above, several causes for crashes and hangs have been identified and eliminated. Future fre:ac releases should run much more stable with these fixes.

Other news

One more thing worth mentioning here is that the Xiph.org Foundation has released updates to the Ogg and FLAC libraries including patches to support the faster CRC checks I implemented for fre:ac in 2018. This can speed up FLAC by 5% and Ogg FLAC by up to 15%. Performance improvements for lossy formats based on Ogg are usually in the 1-2% range.

Another update is the 19.08 release of the Flatpak runtime. fre:ac's Flatpak package has been updated to make use of the new runtime and I took the chance to also update codecs to their latest version while at it.

That's all for this issue. Make sure to come back for the next update in one or two months.

Hi folks, here's the latest fre:ac development status update covering the months of June to August of 2019.

Yes, it's again been three months already since the last update. While my goal is to write monthly reports, my free time is limited and especially in summer, working on fre:ac is competing with other activities like cycling and kayaking, so needless to say it's suffering a bit. The upcoming rainy autumn and cold winter should lend themselves better to spending time on open source projects though. ;)

As already teasered in the previous report, I have some exciting news today and it's about fre:ac's I/O performance.

I/O performance improvements

Doing most of my testing on a relatively fast SSD, I usually found fre:ac's I/O performance to be just fine. It turned out, however, that when putting the output folder on an HDD drive, it can be horribly slow.

This is especially true when doing parallel conversions with lots of threads and writing to an internal HDD. A user with a 16 core / 32 thread Threadripper system approached me, claiming the conversion performance would not scale beyond 8 threads and asked me to have a look at that.

Well, I did and found that while performance was OK when the output folder was on an SSD, it could be more than 20 times slower when writing to an HDD. Looking at the I/O performance in Task Manager revealed that fre:ac was writing a mere 6 MB/s when the disk should be capable of much higher throughput.

The reason turned out to be an oversight of mine when implementing the audio file I/O layer. While fre:ac's I/O system uses buffered I/O in most cases - data is collected in a buffer first and then written in larger chunks - this was not true for most audio data writing (due to a lower - closer to metal - layer being used there). For the low level calls used for writing audio data, buffering was not enabled, leading to audio data being written in many small chunks and congesting the operating system's I/O queue.

Fixing this by enabling buffering on the low level I/O calls instantly improved performance by a huge margin. Here are some numbers for before/after performance with different target formats:

Converting 2586 mixed songs to MP3

Converting 2586 mixed songs to FLAC

So we're looking at a 4x performance increase when writing small (MP3) files to an HDD and up to 20x speed-up with large (FLAC) files. And even when the output location is on an SSD we are seeing more than 2x improvement in some cases. I did see even higher performance gains when converting a smaller number of files, as disk and OS write caches have a larger effect on the result in that case.

If you are on Linux, you can already try these improvements with the continuous AppImage builds or the edge channel Snap.

Multi-threaded adding to joblist

Sometimes, thinking again about a feature previously thought to be difficult to implement will bring up new ideas for a simpler approach. In June, a user brought up the topic of using multiple threads when adding files to the joblist. While I thought about that before, I deemed it too complex to realize in the fre:ac 1.1 development cycle - it was thus on my list for possible 1.2 features.

Thinking about this again, however, I quickly came up with an approach much simpler than my previous ideas. In short, the algorithm assigns tasks to threads in a round-robin manner while the actual adding to the joblist is still done in a single management thread. This is a bit less efficient than an ideal solution, but is so simple in fact, that it could be implemented in just a few hours and without much risk to break anything else in the program.

So this is now implemented and in combination with the aforementioned I/O improvements and some other optimizations, it can greatly speed up the time needed to add files to the joblist. Adding my test library of about 2600 songs in different formats now takes roughly 10 seconds with these changes compared to about 2 minutes with the 20190423 release:

I included the 1.0.32 release in this comparison as it was actually faster than the 20190423 snapshot. This is due to the development releases reading a lot more information (like cover art) from the files. Also, adding the tracks to the tag editor in addition to the joblist takes some time, so it's good to see the new code outperforming any previous version of fre:ac.

As with the I/O improvements, Linux user can already try these changes with the continuous AppImage builds or the edge channel Snap.

Dark mode on macOS

In July and August, I was mostly working on implementing dark mode support for the macOS version of fre:ac.

There actually are two aspects to this. The first being actual work on support for dark color schemes - some elements had colors hard-coded to a value fit for a light theme only. The second - and vastly more difficult one - is reworking the drawing code architecture of the macOS version. The old drawing code used some deprecated patterns no longer allowed in modern macOS. Applications built using an older SDK and supporting only light mode can run in a compatibility mode, however, which is what fre:ac is still doing in the latest release. As soon as you declare dark mode support though, your application will no longer run in compatibility mode and will have to implement the latest drawing paradigms.

So this took a while to implement and is not quite finished yet, but should be fully integrated within the next one or two weeks.

Smaller improvements

• Multi-channel Monkey's Audio
  The Monkey's Audio codec got support for multi-channel audio in a recent release and fre:ac now supports that.

• Tagging improvements
  Some tag fields previously only available in ID3v2 tags are now supported in a wider range of tagging formats. This mostly effects the Mix artist, Grouping, Disc subtitle, Copyright and Catalog number fields.

• Bug report and feature request templates
  The fre:ac issue tracker on GitHub now has templates for bug reports and feature requests which should help improve the quality of issue descriptions and ultimately make it easier and quicker for me to help.

Besides these improvements, several bugs have been fixed in the past three months. I'm working towards publishing a new release, but cannot give a definite time frame for it yet.

That's it for this issue. Make sure to come back here for the next one (hopefully in one month ;)).

Hi all, this is the fre:ac development status update covering April and May 2019.

A lot of interesting things have been worked on in the past two months including a new alpha release, continuous builds for Linux and several improvements and fixes.

New alpha release

The 20190423 alpha release now allows ripping with more CD drives than your system has CPU cores available. This was requested by a user who planned to connect 10 drives to his quad core system for ripping his music collection of several thousand CDs. As the CD drive's reading speed is usually the limiting factor when ripping with the CPU not fully utilized, most modern systems can easily handle multiple ripping threads per CPU core. Previous versions were limited to one thread per core, so the new release allows for great speed ups of such large scale conversion jobs.

Other than that, the new release ships mostly bug fixes. Everything already mentioned in the last report plus some last minute changes:

• Added support for cue sheets referencing multiple multi-track files
• Fixed decoding of very short Ogg files (Vorbis, Opus and Speex)
• Fixed more thread synchronization issues to improve stability

Continuous AppImage builds

The Travis CI system now builds AppImage packages for the four major architectures (i686, x86-64, ARM and ARM64) for every commit to the code repository.

This means that if you are on Linux, you can now try out the latest changes almost immediately. You can find the continuous builds on the downloads page and on GitHub.

iTunes store app support

For users of Windows 10, iTunes is now offered as an app download from the Microsoft store. Unfortunately, this means that the current integration method for the Core Audio encoder with fre:ac no longer works. You currently need to explicitly select and install the non store version of iTunes in order to continue using this high quality AAC codec in fre:ac.

This will be fixed by using an adapted integration method starting with the next fre:ac release. The new version will detect an installed iTunes app and load the Core Audio codec that comes with it.

Other fixes and updates

Several minor updates and fixes have been implemented in the past few weeks and will be included in the next release:

• Improved support for album artist in cue sheets
• Using album artist for single output file name
• Fixed issue with playlist/cue sheet placement when "Use input file folder" option is used
• Fixed invalid file time for CD rips when using "Keep time stamps" option
• Fixed ID3v2 implementation being not completely standards compliant

That's it for this issue. Be sure to stay tuned for the next one which will have some exciting news!