Hi all, it's time for an update on fre:ac development again.

The past month has been quite productive. However, due to some planned features turning out to be more difficult to implement than expected and new bugs surfacing, there is no new alpha release yet.

But let's have a look at the good things - the changes implemented in the past month.

Format selection for single file conversions

Until now, when converting multiple tracks to a single output file, fre:ac could only do that when all input tracks had the same sample format. When mixing different sample rates or mono and stereo tracks, an error message appears to inform you about the issue.

That will officially be over with the next alpha release. From then, when encountering different sample formats, fre:ac will bring up a dialog to let you choose the desired output format.

Improved Delete after encoding option

The option to delete input files after a successful conversion has to be enabled for each new conversion task in current versions of fre:ac. This is to prevent you from accidentally deleting your music library when forgetting about that option being enabled.

Some users, however, use that option regularly and it's tedious for them to re-enable it all the time. Therefore, the next alpha will introduce some changes to it.

There will be an indicator on the Start conversion toolbar button and the corresponding menu entry to signal that the option is active:

Also, it will not disable itself after every conversion, but stay active until fre:ac is restarted. In addition, a checkbox in the confirmation dialog will allow you to keep the option enabled even over restarts, until you explicitly disable it.

Minor improvements

Some minor improvements and fixes have been implemented in the previous month and will be included in the next alpha:

• Reading CD-Text will be supported on Linux and FreeBSD (not on macOS yet, though)
• All CDDB dialogs will be resizable and remember the previous size
• Fixed the quality setting for the FAAC encoder, which was not working correctly
• Fixed a typing issue on macOS where edit fields would stop accepting input
• Improved build system to auto-detect CDK path on Windows (no more editing Makefiles)

Progress on SuperFast LAME

I have made some progress on implementing a SuperFast version of the LAME encoder component. This requires some additional work due to how MP3 framing works. Frames are not independent entities in the MP3 bitstream, but can be intermixed with previous frames, i.e. the actual frame data can start before the frame header in a sparse area of a previous frame in order to make optimal use of the available bytes in frames.

This bitstream has to be unpacked into distinct frames in order for the SuperFast technology to work. The frames are then put in the correct order and are repacked into a new MP3 bitstream. I have a working proof-of-concept implementation of the unpacker already and will go for the repacker next. Once that is done, I will be able to assess performance and integrity of the implementation. What will be left then is to implement a Xing/LAME info header generator and make the proof-of-concept ready for a preview release.

SuperFast LAME will not be ready for the next update, but progress is being made and there should be a first preview available in a few months.

Next alpha and stable release

The new alpha originally planned for January should be available within the next two weeks followed by the release of fre:ac 1.0.32 a few days later.

Hi all, after many months, here is a new update on fre:ac development. As it has been a long time since the last update, many things have happened and I will concentrate on the most important.

Repositories on GitHub

The code repositories for fre:ac, BoCA and the smooth Class Library have been moved to GitHub. The repositories still used the ancient CVS version control system before, so the migration is also a modernization of the project infrastructure. It will make working with feature branches and collaboration with other developers much easier in the future.

Please show your support by starring the repositories on GitHub!

Digital Signal Processing Engine

Since the 20171119 release, fre:ac finally has a working DSP engine that will be further improved in the next alpha.

While the current release enables you to use the resampler component to control the sample rate, the next version will add more format converters and some effect DSPs:

• Sample Format Converter
  This component will convert between different sample resolutions (i.e. 8, 16, 24 or 32 bit) and between integer and floating point samples.

• Channel Converter
  The channel converter will provide channel downmixing capabilities, i.e. converting from 5.1 to Stereo and similar transformations.

• RNNoise
  This is a noise reduction component based on a neural network and designed for speech. You should try it when converting speech recordings the next time - the results are impressive. If you are doing speech recordings regularly, make sure to have a look at the website for more information.

• Rubber Band
  This component can control the speed and pitch of recordings independently. It's great if you are into speed-listening to audio books, but also fun to play around changing the speed of music tracks.

In addition, fre:ac will be able to do automatic conversions when a specific sample format is required by an encoder. For example, the AAC format only supports certain sample rates and earlier versions of fre:ac showed an error message if the input did not match it. Future fre:ac releases will automatically upsample to the next supported rate instead.

SuperFast Codecs

In September, I published my work on speeding up encoding using multiple parallel encoder instances. Check out the corresponding article for a fre:ac preview release with this technology - dubbed SuperFast Conversion - enabled. It will soon make it's appearance in an official fre:ac release as an experimental option and I hope to be able to enable it by default in a later release.

The preview release mentioned above includes SuperFast versions of the Opus, FAAC and Core Audio encoders. Since that release, the technology has been implemented for the FDK-AAC and Speex encoders as well and there will soon be an update. I also plan on implementing this for the LAME MP3 encoder, but that will take some time due to the peculiarities of the MP3 format and related difficulties in applying this technology.

Core Audio on x64 Linux

Prior to the 20171119 release, to get the Core Audio encoder working on 64 bit Linux, you needed a 32 bit Wine installation. While this combination is quite common, there are some who use 64 bit Wine instead. The 20171119 release now supports both variants making it much easier to use the Apple encoder on 64 bit Linux.

Codec Updates

There have been several important codec updates during the last few months. LAME 3.100 has been released more than five years after 3.99.5 and work on the FAAC encoder has resumed after more than 9 years of almost complete inactivity. The new versions are included in fre:ac 1.0.31a and the 20171119 alpha release.

Also, the Monkey's Audio (APE) encoder is now available on non-Windows systems thanks to the help of its developer. It was great to work with him to make Monkey's Audio more portable.

And more...

There are many more smaller improvements and fixes that went into the latest releases or will go into the upcoming ones, but after such a long time it's really too much to mention everything here in detail. Here are just some keywords for the more notable ones:

• Fixes for running on macOS 10.13
• Allow CDDB queries when no CD drive is present
• Fixes for USB CD-ROM drive detection
• Made AAC decoders work independent of file extensions

Upcoming Releases

Work on the next fre:ac 1.1 alpha release is progressing really well and I expect it to be out in January. It will be almost feature complete in terms of my plans for 1.1, so it should be the last alpha release before fre:ac 1.1 beta 1. Hooray!!! :)

There will also be an update to the 1.0.x release series with some minor fixes probably in February.

I always liked doing performance optimizations – such projects are often fun to work at and it's very rewarding when an idea actually works out in practice.

tl;dr: I implemented multi-threaded drivers for Opus Audio as well as the FAAC and Apple Core Audio AAC codecs – more to come. Scroll down or click here to download experimental fre:ac builds with this technology.

Introducing SuperFast codec drivers for fre:ac

The biggest step for the fre:ac project regarding performance was the introduction of a multi-threaded conversion engine in 2014. Running multiple conversions at the same time allowed fre:ac to scale almost linearly with the number of CPU cores, compared to converting only one file at a time.

Serial vs. parallel conversion in fre:ac

Parallel conversions, however, only help when there actually are multiple items to convert in the first place. When converting less files than there are CPU cores available, it's still inefficient. And when combining multiple files into a single output file, there is still only one CPU core used.

Converting less files than there are CPU cores and converting to a single output file

So, while a big step forward, the situation was still a little unsatisfying in certain cases which made me explore ways to further optimize the conversion engine.

Choosing the best method

In general, there are three different ways to distribute the work done by an audio codec to multiple CPU cores:

1. Low level data parallelism – parallelizing loops
   To make use of low level data parallelism, you look for loops that do the same operation on many data values. A basic example would be multiplying a large array of values with a constant expression. You can spread the work over multiple threads, each doing the operation on a part of the values. For such optimization, you would usually use something like OpenMP which makes loop parallelization pretty easy. When it comes to complex algorithms, though, not all loops will be parallelizable, limiting the maximum speed-up you can gain with this method. An example of this approach are the Lancer optimizations for the Vorbis audio codec.

2. Task parallelism – pipelining subtasks
   A second method is pipelining. It can be used if the work to be done consists of multiple stages. For an audio codec, these stages might be MDCT processing (converting time-domain samples to frequency values), psychoacoustic analysis and actual audio encoding. While the later stages depend on the results of the earlier ones, audio codecs usually work on blocks of samples, so a later stage can start its work as soon as the preceding stage finished a block. However, this approach only scales well as long as you have enough compute-intensive stages to fully utilize the available CPU cores. It can be combined with loop parallelization, though, to achieve further speedup. LAME MT is an example of a project using this method (without additional loop parallelization).

3. High level data parallelism – splitting work into fragments
   The third method splits the work to be done into multiple parts each processed by a separate thread. For example, the first and second half of an audio file can be encoded separately and the results later be joined back together. Seeming very easy at first glance, this method has some issues due to frames in an audio file not being completely independent. The LAME MT project tried this method at first, but later found that the project's constraints of producing a result bit-identical to the non-parallel version could not be met with this approach and resorted to pipelining.

Looking at and thinking about the three methods, I quickly came to the conclusion that the first two were not feasible for a project like fre:ac. They would require modifications deep in the respective codecs and each new codec release would require reviewing the changes. Such modifications are better suited for being done in dedicated projects like Lancer or LAME MT.

The third method, however, could theoretically be implemented on a higher level – just run several instances of a codec in parallel and concatenate their output back together in the correct order.

This seemed reasonably easy and had the advantage that the same method might be usable for different codecs. I decided to try implementing this on top of the Opus codec first, because it has a constant block size and outputs raw packets that can be intercepted and reordered before being written to the output file.

How it works

For the first proof-of-concept implementation, I made the codec driver split the input data into blocks of several frames of audio data and distribute those blocks to worker threads in a round-robin manner. Except for very short files, there will usually be many more fragments than there are threads to be used, which allows for quicker distribution of work to the threads.

The worker threads then do their job in the background and collect packets of encoded audio data obtained from their respective codec instances.

When it's a threads turn for getting new data, the codec driver asks it for the collected audio data packets, writes those to the output stream and finally assigns a new block to the thread.

Basically, the inside of the main conversion loop looks like this:

Worker *worker = workers.GetNth(nextWorker++ % workers.Length());

/* See if the worker has some packets for us.
*/
if (worker->GetPackets().Length() != 0) ProcessPackets(worker->GetPackets(), ...);

/* Pass new frames to worker.
*/
worker->Encode(samplesBuffer, ...);

Details

The naive implementation of splitting the audio data into several parts encoded by separate codec instances and concatenating the output back together, proved to be problematic, though.

As mentioned above, frames are not completely independent of each other. Transformations and filters applied during the encoding process need multiple frames worth of audio data to adapt, so concatenating packets created with different initial filter states can lead to heavy distortions.

Difference signal of single vs. multi-threaded conversion

To avoid this effect, the audio fragments to encode have to overlap by a few frames to give the filters enough time to adapt. After trying out different values, I settled with an overlap of 8 frames for an Opus frame size of 10ms or more (a larger overlap is necessary at shorter frame sizes).

Difference signals with 1 and 8 frames overlap

With an overlap of 4 or more frames there are no more distortions. The remaining differences are on the same level as when encoding the same file starting at different offsets and should be unnoticeable.

Resulting implementation

The current implementation of this method for Opus and AAC uses blocks of 128 frames with an overlap of 8 frames. That's a 6.25% or 1/16th overlap limiting the maximum possible speedup to 16x. In practice, though, even if you have a 16 core CPU, the actual speedup will be lower because of non-parallelized decoders and additional work needed for thread management.

The multi-threaded codec driver solves the aforementioned problems of parallelizing conversions to a single output file and improving efficiency when converting less files than there are CPU cores.

Serial versus multi-threaded processing when converting to a single output file

Multi-threaded processing when converting less files than there are CPU cores

Performance numbers

The actually achieved speedups are quite significant. So good actually, that even on a 6 core CPU the conversion speed is often limited by decoding speed which makes me think about future possibilities of parallelizing the decoder side as well.

Multi file mode vs. single file mode

Speed comparison of regular vs. SuperFast codecs in multi and single file mode

In multi file mode, the SuperFast codec drivers are only slightly faster than the regular ones. Only one codec instance per track was used in this test and the performance advantage solely stems from decoding and encoding being done in separate threads.

In single file mode, though, the SuperFast codecs show their full potential. Using four threads, the conversion is already three times faster than with the regular drivers, which use only a single thread in this mode.

Note that the multi-threaded Opus encoder will exhaust its full potential only with 48 kHz audio data as that is the only sample rate natively used by Opus. The resampler used for feeding other sample rates to Opus still runs in non-parallel mode. I'm looking into ways of parallelizing it too.

What's next?

I chose Opus and AAC for the initial implementation of this idea, because they use constant frame sizes and straight forward frame packing. Thus, it was relatively easy to implement this idea on top of them without having to worry about too many side effects.

Adapting this method to other AAC codecs like FDK-AAC or other codecs with constant frame sizes like Speex should be relatively easy and will be done soon.

After that, the next step will be implementing this technology on top of the LAME MP3 encoder, which will be a bit more challenging. In MP3 files, frames can actually start before their frame header to make use of unused bits from previous frames. Therefore, you cannot simply concatenate the output of the encoder instances, but need to unpack the frames first and re-pack them when writing the output stream.

Some other codecs don't lend themselves very well to this kind of optimization. These include Ogg Vorbis (because of how block size switching changes the resulting frame lengths) as well as FLAC and WMA (because their APIs do not allow intercepting packets before writing the output stream). It currently does not seem feasible to implement this technology on top of those codecs.

Downloads

[Update: Multi-threaded FDK-AAC and Speex components have been added in the second preview release. The links below have been updated.]

Download an experimental fre:ac build with multi-threaded Opus, FAAC*, FDK-AAC, Core Audio and Speex converters:

• Windows: x86-64, i686

• macOS: Universal Binary (x86-64, i686 and PPC)

• Linux: x86-64, i686

• FreeBSD: x86-64, i686

* The FAAC codec is provided as a fallback when neither FDK-AAC nor the Core Audio encoder are available.

Source code

The source code for the multi-threaded codec drivers can be obtained at:

https://github.com/enzo1982/superfast

Here's an update on fre:ac development in the past month. Development in April was very active with work on many different areas and I can finally talk about some upcoming features now.

More bug fixes

I talked a lot about bug fixes in the previous report and have some more of them for this issue, too:

• Haiku OS: fre:ac running slowly when started with arguments
  This one was tricky and riddled me for quite a while. On Haiku OS, and only there, fre:ac would run very slowly - to a point where it would be unusable - when started with arguments on the command line. Start it without any arguments and it would run at normal speed.

  At first, I added some timing code and it showed that when running ./freac abc from the command line, many operations, like loading codecs and extensions, took much longer than when simply running ./freac. Really weird as fre:ac doesn't do anything with these arguments, but simply ignores them.

  I left this untouched for a while and came back after a few days. Fortunately, I quickly found out what was going on then: fre:ac tries to find the directory it is executed from in order to locate its resource files (language files, images, extensions etc.). This part is system specific and on Haiku the original implementation parsed the output of the ps command in order to get that path. This would normally yield something like /boot/common/non-packaged/bin/freac which could be interpreted as a filename to get the path. Unfortunately, when run with arguments, the arguments would be included in the ps output to give something like /boot/common/non-packaged/bin/freac abc which could no longer be interpreted as a filename. The routine would thus return a null path and would try to find the correct execution path again when invoked the next time, running and parsing ps over and over just to get the same null result again and again and causing a massive slowdown of the application.

  The solution was to query the path using the designated Haiku API, asking the global be_app object for it.

• Windows: fre:ac hung when trying to stop paused playback
  This one also was quite tricky to fix: Due to a bug in fre:ac's DirectSound output component, it hung when trying to stop a previously paused playback. I.e., select a track, hit the play button, hit the pause button and finally hit the stop playback button and fre:ac would hang.

  The reason for this was the DirectSound output component reporting that samples could be written even if the buffers were already filled. It would then block when fre:ac actually tried to write the samples, waiting for the buffers to empty enough so they could take the new samples. When paused, however, the write function would wait and block indefinitely as the buffers would never be emptied.

• OpenBSD: fre:ac hung because of timer bugs
  On OpenBSD, fre:ac uses a threads-based timer implementation for things like blinking cursors. This is necessary because OpenBSD does not support POSIX timers based on signals. The threads-based timer implementation, however, was not well tested and contained several synchronization bugs, causing fre:ac to hang after using the UI for a while.

  This was a little difficult to debug, unfortunately, because the GNU debugger available for OpenBSD was not very reliable. I ended up enabling threads based timers on Linux and debugging there. After a few hours of fixing synchronization issues, there now is a stable timer implementation for OpenBSD and other systems lacking POSIX timers (like GNU Hurd, yeah!).

Performance improvements

In addition to fixing bugs, I was working on further speeding-up conversions, finding several opportunities for improvement:

• Waiting faster
  Sometimes a process has to wait for something else to be ready and there were several places in fre:ac's code with room for improvement in this regard.

  I had a look at all those places and improved many of them to use less CPU cycles while waiting and reduce overall waiting times. The former reduces fre:ac's CPU usage with some codecs and slightly improves conversion speed when using all CPU cores while the latter reduces the time taken for switching from one track to the next during conversions. Together, these improvements should provide nice speed-ups for conversions of multiple tracks, especially on processors without SMT/HT.

• Improved duplicate filename check
  The check for duplicate filenames taking place before each conversion job can take quite some time when lots of files are involved. In a test setup, I had a conversion job with several thousand files spending 15 seconds for the check. By analyzing the involved routines with a performance profiler, I was able to identify where it spent most of the time and could reduce the time by a factor of 5. The aforementioned test setup now does the check in about 3 seconds instead of 15.

• Faster single file conversions
  fre:ac uses a parallel conversion engine to speed up conversions of multiple files. When converting only a single file or when combining multiple input files into a single output file, however, only a single CPU core is used.

  I'm currently looking into ways to improve performance for such single file conversions, too, and so far, things are looking really good. I expect to be able to talk about this in more detail and present some performance numbers in next month's report.

Other improvements

Besides performance improvements, fre:ac also got some improvements in other areas:

• macOS and Haiku: Improved CDDAFS handling
  macOS and Haiku expose audio tracks of inserted CDs as virtual .aiff and .wav files. This is great for quickly copying tracks to your computer without the need for a dedicated CD ripper. However, without special precautions, it gets in the way of the parallel conversion engine in fre:ac. fre:ac sees the tracks as files and tries to convert them in parallel - CD drives, however, are not very good at reading multiple tracks at the same time - they keep constantly repositioning the laser and the whole process gets really slow.

  The next snapshot release will notice when such virtual CD track files are added to the joblist and treat them like regular CD tracks, disabling parallel conversions for them.

• Improved audio format support
  A user sent me some .m4a files that fre:ac was unable to open. They were obtained through an online YouTube to audio conversion service and turned out to be invalid, missing a table of contents section. The MP4v2 library used by fre:ac to access the audio content of .m4a files is unable to handle such files and thus, fre:ac was unable to open them. fre:ac also uses the avconv/ffmpeg utility to read some other file formats, though, and it turned out that this tool can read such invalid files. So what the next snapshot release will do is pass files on to avconv/ffmpeg if the dedicated .m4a decoder is unable to handle them. Reading the files that way is a bit slower, but at least you will be able to access and convert them.

  While at it, I also added support for reading .aea (ATRAC-1) files as per another user's request.

A DSP engine

The big feature of the next snapshot will be a DSP or digital signal processing engine. I talked about this already one year ago, but did not finish it back then.

This time, however, I'm positive that I can complete it for the next snapshot release. At first, it will provide sample rate conversion only. More filters will be added in following releases.

fre:ac 1.0.29

While all of the above applies to development towards a new snapshot release, I also implemented a significant change for the next stable release, fre:ac 1.0.29. That version will switch to using mpg123 instead of MAD as its MP3 decoder. Unlike MAD, the mpg123 library is under active development and handles some MP3 files much better than MAD. The mpg123 decoder has been the default MP3 decoder in fre:ac development snapshots for a while and should be very stable and reliable.

This closes this months report. Be sure to check for a new snapshot release around the end of May and come back for a new development update in early June.

Hi folks, here's a new update on fre:ac development progress. Sorry for not giving an update last month - I was really busy preparing the March snapshot release. Thus, this update covers the past two months - February and March - and got rather lengthy.

fre:ac 1.0.28

fre:ac 1.0.28 was finally released in February with the FLAC codec updated to version 1.3.2 and an important fix for cover art handling. Previous versions of fre:ac had problems handling files with invalid tags that announced the presence of cover art, but contained no actual data. The 1.0.28 release fixes this.

20170317 snapshot release

After fre:ac 1.0.28 was out, I concentrated on finishing the snapshot release. Lots of improvements, such as title info extraction from file names,  per-folder playlists/cuesheets or reading embedded cuesheets, have been mentioned in previous posts already. Here are some more that I didn't cover here yet:

• Support for album artist
  Likely the most important addition is support for the album artist tag field. fre:ac now reads and writes this value and adds an edit field for it in the tag editor. In addition, the new snapshot introduces an <albumartist> placeholder for the filename pattern and supports an optional joblist column for the album artist.

• freaccmd improvements
  The freaccmd command line utility also got some improvements in the March snapshot. It now supports all encoders available in the GUI version and recognizes a new option to select from different available configurations.

• HTTPS support
  The smooth Class Library which forms the base for fre:ac now uses libcurl for HTTP transfers and enables support of the HTTPS protocol. While there are not many places in fre:ac where that matters at the moment, it will become more important in future versions when the video downloader extension will be made available again.

At the moment - besides other things - , I'm working on creating packages for the Haiku operating system (mentioned here in December). I already made myself familiar with Haiku's package management system (which really is one of the best I've ever come across), but still have some issues to fix before I can provide official fre:ac packages.

The bug hunting season is open

After a release usually is bug hunting time - even more so with two releases from different branches, so in the past three weeks I was mostly fixing issues reported by users:

• Non thread safe LAME decoder
  A user running fre:ac on Linux reported garbled output when converting MP3 files in multi core mode. This turned out to be an issue with the LAME MP3 decoder not being thread safe - which unfortunately is not mentioned in the LAME docs and thus was not taken into account by fre:ac. The next snapshot will fix that by disabling parallel mode for the LAME decoder. Fortunately, the MAD or mpg123 decoders, which do not have such issues, are used on most systems. Also note that this only affects the LAME decoder, not the encoder which is perfectly thread safe.

• Problems with CIFS/SMB shares
  The current version has problems opening files and folders on mounted CIFS/SMB shares. This turned out to be the result of the GNU C library, glibc, and the CIFS mounting utility not playing together nicely. When calling stat() on a file or folder name to see if it actually exists, glibc will internally call stat64() and CIFS will generate a 64 bit inode number which glibc in turn will respond to with an overflow error, because it cannot convert it into a 32 bit value for the original stat() call. The solution is to use stat64() from the beginning, which fre:ac will do starting with the next snapshot.

• Access violations with the FDK AAC decoder
  When reading AAC files with the FDK AAC decoder available in some Linux distributions, the decoder can generate an access violation by reading a few bytes past the supplied buffer containing the AAC sample. This will crash the application if the buffer ends near a memory page boundary and the next page is protected because it belongs to another process. The chance for this to happen seems to be quite low, however, as I got crashes only approximately once every 4000 files. The next snapshot will fix this by allocating slightly larger buffers for the FDK decoder. In addition, the decoder's behaviour will be documented in the next release of the FDK library.

• Minor bug fixes
  In addition to the above, several minor bugs have been fixed. These are things like graphical glitches when displaying the progress bar or toggling the title info area. Too many to mention them all here.

This closes this months status update. Keep checking this blog section for the next update with an outlook on changes sheduled for the next snapshot.

Here's the fre:ac development status update for January 2017. It's already February now, so let's not lose any more time and go right ahead.

Work on the next snapshot

Since the last update, a lot of changes for inclusion with the next snapshot have been implemented. These are the most important ones:

• Advanced info extraction from file names
  When no tag information is available for a file loaded into the joblist (as often happens with .wav files), current versions of fre:ac take the file name and treat the first part before a " - " delimiter as the artist and the last part as the title. So, for example, in Ed Sheeran - Shape of You.wav the artist and title will be correctly recognized. With more advanced naming schemes, fre:ac can easily get confused, though.

  The new algorithm knows and recognizes lots of different popular naming schemes. For example, it now takes the folder name into account to recognize patterns like <artist> - <album>\<track> - <title> and it looks for numbers in the file name and treats them as track numbers.

• Easier format selection for codecs supporting multiple formats
  Some encoder components like Core Audio or SndFile support different output formats. For example, SndFile can create .wav or .aiff files. Starting with the next snapshot, fre:ac will allow you to select the desired output format directly from the Start encoding drop down menu. It's no longer necessary to go to the configuration dialog to change the output format.

• Create one playlist / cue sheet per folder
  When converting multiple albums in one conversion run, current versions of fre:ac create a single playlist or cue sheet file with all the tracks of all albums, which is probably not what you want in most cases.

  Starting with the next snapshot, there will be an option (enabled by default) to create separate playlist and cue sheet files per output folder. So, if you use a pattern like the default <artist> - <album>\<artist> - <album> - <track> - <title>, you will get separate playlist and cue sheet files for each album.

• Faster editing of tracks with cover art
  In the current snapshot version, performance can get really slow when editing title information of tracks with cover art. This will be fixed in the next snapshot thanks to fre:ac user Shri, who reported this behaviour as a bug on SourceForge.

• Open the output folder from the main window
  Next to the name of the output folder at the bottom of the main window now is a button to open that folder in your systems file explorer.

• Polishing for an upcoming beta release
  Several minor changes have been implemented to get fre:ac 1.1 closer to a beta release. For example, the macOS version now displays conversion progress in the dock, fre:ac's application name is no longer shown as unknown in the Gnome panel on Linux or FreeBSD and fre:ac recognizes configuration files of 1.0.x releases and keeps most settings when upgrading from such a version.

Some more changes are queued for the next snapshot, but are not quite ready yet, which is why there was no new snapshot release in January. I hope to be able to talk about those changes in next month's issue.

1.0.28 coming soon

I hoped to have a new stable release by now, but things turned out a little more complicated. A compilation bug was found in FLAC 1.3.2 and I decided to wait for a fixed release. However, probably due to lots of people submitting various fixes for FLAC 1.3.2, that have to be reviewed and integrated, a new version is not available yet.

Thus, I decided to just apply the patch for the compilation bug to FLAC 1.3.2 and make a fre:ac release with it. I expect to be able to push out fre:ac 1.0.28 in the next few days.

That's it for this update. Stay tuned for the 1.0.28 release and a new status update next month.