Main Menu

News Feed

Welcome to the fre:ac developer blog. I will post status updates and other information about fre:ac development here.

fre:ac development status update 06/2018

Written by Robert

Wednesday, 04 July 2018 23:39

The June development update is overdue, but better late than never, here it is. It was a very productive month, so let's get right to the good stuff.

Parallel conversion jobs

The current alpha release supports only one conversion job at a time. Multiple tracks in a conversion can be processed in parallel, but when you try to start a new job while a conversion is still running, you just get a message asking if you would like to schedule the new job for after the current one is finished.

The next release will enable parallel conversion jobs. As long as there are CPU threads left, multiple conversions, possibly using different settings, can run at the same time. This helps when converting multiple albums to a single file per album or when ripping CDs using multiple drives.

Improved handling of automatic ripping

This brings us to the next item. There are some issues with the current alpha when using the automatic ripping option with multiple drives. When inserting a disc while other tracks are still in the joblist, the new ripping job will try to process those other tracks again, leading to some tracks being ripped more than once. Also, the new job will not start before any currently running rip is finished. Both issues will be fixed in the next alpha which makes ripping with multiple drives much more usable.

Fixed metadata bug with Core Audio on Windows

In May, a user opened an issue on GitHub reporting that when converting ALAC files to AAC using the Core Audio encoder on Windows, tags were missing on some files. I could easily reproduce the issue, but it seemed really strange. It occurred only when converting files decoded with an external decoder (i.e. a separate .exe called by fre:ac) and the selected encoder was Core Audio. That didn't seem to make any sense at first.

It turned out to actually be a bug in Apple's Core Audio implementation on Windows. It would make file handles created by its API calls inheritable by sub-processes. The sub-processes (in this case the external decoders) would then inherit any open handles and lock the respective files, making them unwritable by the tagger component.

Making handles inheritable is something that an API never should do as it can lead to unforeseeable behavior and very difficult to analyze bugs.

Fortunately there is a work-around by avoiding the problematic APIs. The next alpha release will include this fix.

Automatic codec builds

Till now, all the codecs included with fre:ac are built manually: Set the correct compiler flags for each codec on each supported OS, apply necessary patches, configure the codecs with the right flags and run make to build them. This costs a lot of time whenever a new codec version is relased and also is a bit error-prone, so it was necessary to change it.

I built a script to automate all the steps listed above for most of the necessary codecs and some other libraries. The script can compile FAAC, FAAD2, FDK-AAC, FLAC, LAME, libav, libogg, libsamplerate, libsndfile, Monkey's Audio, mpg123, Opus, RubberBand, Speex, Vorbis and WavPack on Windows, macOS, Linux and FreeBSD. Whenever a new version of one of these libraries is released in the future, I can simply update the package download URL and run the script to build a new release.

Reworked donation dialog

The donation dialog has been reworked to support more payment types. Previously supporting only PayPal, the new dialog adds support for Donorbox, SEPA transfers and the Bitcoin and Ethereum crypto currencies.

Other items

A number of other changes have been implemented in the past month, the most notable of which are:

HiDPI iconsPreparing for the upcoming beta release, I added higher quality versions of the toolbar icons that now look crisp on HiDPI displays like Apple's Retina screens.

Completely translatableIn the current alpha release, not all strings are translatable. This applies to configuration dialogs for external codecs especially. The next alpha will fix this and enable translations for WavPack, Musepack, OptimFROG and TAK configuration dialogs along with some other previously untranslatable strings.

Fixed MP4 metadata bugWhen converting multiple files in parallel to AAC or ALAC output, it can happen that some files end up being unoptimized due to a bug in the MP4v2 library used by fre:ac. Optimization of MP4 files means that tags and the seektable are moved to the beginning of the file for more efficient processing. The next alpha release will include a work-around for the MP4v2 bug fixing the issue of MP4 files not being optimized.

Downloads now hosted on GitHubThe links on the downloads page now point to GitHub instead of SourceForge. This enables direct downloads without an intermediate page to choose a mirror and allows downloading using right-click + save as.

SuperFast LAME status

There were some open issues with the SuperFast LAME implementation when I last wrote about it in the April status update. These have been fixed now and there will be another SuperFast preview release including LAME support very soon after the next alpha. I'm also preparing a technical article about how the MP3 bit reserviour is handled in SuperFast LAME. This should be out within one week from now.

That's it for this month. Be sure to come back in about one month for the next update.

fre:ac development status update 05/2018

Written by Robert

Thursday, 31 May 2018 22:35

Hi all, it's time for an update on fre:ac development again. The past month was quite productive and so I have lots of things to talk about.

Integration with Travis CI

The GitHub projects for the smooth Class Library, BoCA and fre:ac are now integrated with the Travis CI platform for automated build tests. Every commit to one of these repositories now starts automatic build processes on Linux and macOS to check if anything got broken. This improves the development process by ensuring that build-breaking issues will be noticed quickly.

The build processes are also started for pull requests, so anyone who submits a patch can immediately see if it breaks anything.

Fast CRC patches accepted into FLAC and Ogg

The patches for faster CRC calculations I wrote about last month have been accepted by the upstream FLAC and Ogg projects. So with the next FLAC and Ogg releases, any software using them will benefit from faster encoding and decoding.

Allowing playback during conversions

Until now, it's not possible to play a track in fre:ac while a conversion is running. This limitation will be lifted with the next alpha release. You will be able to play tracks during conversions as long as they are not on a CD that is currently being ripped from.

Faster AAC, APE and WMA encoding

fre:ac's AAC, Monkey's Audio (APE) and WMA encoder components use temporary files for writing output data. The content of these files is transferred to the actual output file after the encoding process is finished which causes a small delay at the end of each conversion. The next alpha release will fix this by writing directly to the actual output file from the start.

Making this possible required an addition to the internal IO filter interface and extensive testing. This is why it was not done like this earlier.

Improved handling of album artists

Starting with the next alpha release, fre:ac will make use of the <albumartist> placeholder in the default output filename pattern. This prevents the creation of separate folders for each track when dealing with sampler CDs. On samplers, the previously used <artist> placeholder would resolve to a different artist for each track, while <albumartist> will usually be something like Various artists and be the same for every track.

SourceForge Project of the Month

fre:ac has been chosen as the SourceForge Project of the Month of May 2018. This is the second time fre:ac won this award after October 2015. You can read a short interview with me in the SourceForge blog.

This closes this month's issue. Be sure to come back in June for another update.

fre:ac development status update 04/2018

Written by Robert

Tuesday, 01 May 2018 12:28

It's time for a new development status update after an interesting month.

Optimized CRC routines for audio codecs

In case you missed it, here is my article on speeding up LAME, FLAC, Ogg and Monkey's Audio with faster CRC checks. The proposed CRC algorithm is roughly 5 times faster than the one previously used and results in a speedup of about 5% for FLAC encoding and decoding. Patches have been submitted to the upstream projects and I hope for integration in official releases of these codecs.

Fixed crashes with local CDDB queries

A user reported occasional crashes when querying a local CDDB database on Linux. This turned out to be a thread-safety issue that manifested itself only when the CDDB query dialog was displayed and then immediately closed before the main thread finished processing the window mapping event.

The issue affects all systems using the X11 window system, so it can happen on Linux, FreeBSD and other Unix-like systems.

This and another issue that I found while investigating it will be fixed in the next alpha release.

SuperFast LAME nearing completion

A whole bunch of changes have been incorporated into the SuperFast version of the LAME MP3 encoder component. It's almost complete now and an official preview release is getting closer.

This month's changes include:

Support for CBR mode and VBR rate limiting

Support for MP3s with frame CRCs

Writing Xing header table of contents

Writing Xing header CRCs

There is just one item left on my list now which is related to handling the bit reservoir in high complexity situations (especially with MPEG 2 streams at 22.05 or 24 kHz). In that case it can happen that an encoder thread tries to use more reservoir than actually is available. Special handling has to be implemented to resolve such situations. I hope to be able to finish this in May.

While waiting for SuperFast LAME, make sure to check out the 2nd SuperFast preview release with added support for FDK-AAC and Speex and tuning for Opus and Core Audio AAC.

Faster CRC checks to speed up codecs

Written by Robert

Sunday, 29 April 2018 22:33

So, I kind of stumbled into this, but always looking for possible optimizations, I simply had to explore it...

tl;dr:I accelerated checksum calculations and thus encoding times of LAME, FLAC, Ogg and Monkey's Audio using an optimized CRC algorithm. Find patches at the end of this post. These will be part of the next fre:ac 1.1 alpha release.

Calculating Xing/LAME header CRCs

Working on the LAME MP3 implementation of my SuperFast technology, I came across the necessity to do CRC checksum calculations. Every MP3 created by LAME has a Xing or LAME VBR header at the beginning. It contains index points to the MP3 as well as information about duration and gapless playback. At the end of this header, there are two CRC checksums, one for the MP3 bitstream and one for the header itself.

As the bitstream repacker used in SuperFast LAME changes the MP3's internal structure, an update of the Xing/LAME header's CRC values is necessary afterwards. I started with a simple implementation of the CRC16 algorithm that I wrote for the smooth Class Library. This created a small delay at the end of each conversion when the CRC for the MP3 file is updated. Not a big deal for the usually small MP3s weighting in at 3-4 MB. With larger files, however, like when converting a whole album to a single output file, it became painful. The CRC calculation added a delay of half a second for a 60 MB file on my i7 6900K system. On slower systems it would be much more.

Steps to optimize the calculation

The first thing I tried was using compiler optimizations for the CRC routines (GCC's -O3 instead of -Os). This brought the delay down to about a quarter second. Still too much for my taste, though.

I then started looking for optimized CRC algorithms and found Matt Stancliff's crcspeed repository. It is based on an algorithm developed by Intel that uses additional lookup tables to enable processing of multiple input bytes in a single step. There are different variants of this algorithm circling around, processing different numbers of bytes in each step, but it's generally called slicing-by-X (where X is usually 2, 4, 8 or 16).

I updated my CRC implementation to use the slicing algorithm and did some measurements. The slicing-by-8 variant turned out to be roughly 10 times faster than my original version and 5 times faster than the GCC -O3 compiled one. There was very little additional speedup when using slicing-by-12 (which I found to be the fastest) or slicing-by-16, so I decided to stick with slicing-by-8 as a good compromise between speed and memory requirements. Using the slicing-by-8 algorithm reduced the delay at the end of the 60 MB MP3 conversion to just a few 10s of milliseconds.

But I did not stop there...

Looking further

So, if I have to calculate CRC checksums for the Xing/LAME header, LAME itself will have to do the same. You just don't notice a delay, because the calculation is not done at once at the end, but spread over the whole encoding process. But does LAME use an optimized CRC implementation? As it turned out, no.

I updated the LAME CRC routines with the slicing-by-8 algorithm and got a speed-up of only 0.5%. Not much, but I wondered if other codecs (especially lossless ones that generate more data) might benefit more.

I looked further and found non-optimal CRC implementations in FLAC, Ogg (used for Opus, Vorbis and other codecs) and Monkey's Audio. Replacing them with the optimized algorithm yielded similar results to LAME for the lossy formats. The lossless formats, however, benefit more from the optimization and are sped up by about 5% due to more data being generated. When using Ogg FLAC, the speed-up is roughly 10% due to CRC's being calculated for both, the FLAC audio frames and the Ogg container pages.

So we get up to 5% speed-up in the usual case and around 10% improvement for the Ogg FLAC format. All by simply replacing the CRC algorithm with an optimized version.

Technical considerations

The original Intel algorithm and Matt Stancliff's version require separate implementations for big-endian and little-endian CPUs. I converted the algorithm to an endian-independent form, i.e. only one variant for all processors. I did not measure any significant speed difference after making the code endian-independent when compiling with optimizations turned on.

It's possible to speed up the CRC calculations even more using other methods such as using the PCLMULQDQ instruction on modern x86 CPUs. However, that would make the code depend on that platform and probably provide only marginal additional speed gains.

My implementation uses static lookup tables for LAME, FLAC and Ogg. This blows up code size a bit and I would have preferred calculating the tables on the fly on first use. That's difficult to get right in a portable, thread safe way in plain C though, so it is used only for Monkey's Audio which is written in C++ (allowing dynamic initialization of static data).

Speed gains

Here are some numbers showing relative speed gain when encoding and decoding with different codecs (all used with default settings):

Codec

Encode

Decode

LAME

0.5%

-

Opus*

0.5%

1%

Vorbis*

0.5%

2%

Monkey's Audio

4%

-

FLAC

5%

5%

Ogg FLAC

10%

15%

* Opus and Vorbis themselves are not optimized, but use the optimized Ogg container library.

The patches

Here are my patches to update the mentioned codecs' CRC calculations to the optimized slicing algorithm:

The patched codecs will be used in the next fre:ac 1.1 alpha release and I will contact the maintainers of these projects to request integration of the patches in official releases.

fre:ac development status update 03/2018

Written by Robert

Saturday, 31 March 2018 17:45

Hi and welcome to the March 2018 status update on fre:ac development.

The past month finally saw the 1.0.32 release and a new fre:ac 1.1 alpha providing lots of fixes and new features. Apart from that, I worked mostly on two things: Making the config dialogs for external codecs more beauti- and useful and implementing the repacker part of the upcoming SuperFast LAME encoder.

Improved config dialogs for external codecs

The configuration dialogs for external codecs are generated on the fly from a description provided by the external codec's XML script. Until now, that dialog was very small and displayed only one option at a time:

The next alpha will feature an improved configuration dialog generator. It will create dialogs that show all the options at the same time and provide more space for them:

Progress on SuperFast codecs

I spent a lot of time on writing the repacker part for the SuperFast LAME encoder in the past few weeks. A proof-of-concept was done quickly, but implementing all the edge cases turned out to be more difficult than I initially thought. Particularly, correct handling of the bit-reservoir was a lot of work. Nevertheless, it's working great now and I'm now in the testing stage.

A few things are still missing, like support for CBR mode, CRC checksums and generating a valid Xing header, but I am confident that I can implement these things in the next few weeks.

I'm currently preparing a new SuperFast preview release based on fre:ac 1.1 alpha 20180306 which I plan to release in the next few days. As mentioned earlier, this will not include the SuperFast LAME encoder yet, but introduce SuperFast FDK-AAC and Speex along with some tweaks for the other codecs.

That's it for the moment. Make sure to come back in a month for another update.

fre:ac development status update 02/2018

Written by Robert

Wednesday, 21 February 2018 19:51

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.