Menu Content/Inhalt
Home Developer Blog fre:ac fre:ac development status update 03/2017

News Feed

fre:ac Developer Blog
fre:ac development status update 03/2017 Print
Written by Robert   
Tuesday, 04 April 2017 20:42

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.


Share Add to StumbleUpon Add to diigo