Here's what happened in fre:ac development in October. Progress was a little slow this month, but I still have some interesting bits and pieces.

Four weeks ago, I released a new snapshot version that fixed several problems found in the September release. The 20141005 snapshot appears to be quite stable and reliable and I suggest everybody to test it! I'm especially interested in your results if you are running fre:ac on a dual or quad core Power Mac. Please email me if you tried fre:ac 20141005 on such a machine.

After the October snapshot release, I made plans on what to include in the next one. I already developed an adapter to make the Core Audio encoder available in the 64 bit Windows version. The underlying issue was that iTunes and the Apple Application Support libaries are available in 32 bit only and cannot be used directly by 64 bit applications. The adapter starts a 32 bit helper process and delegates the actual encoding work to it. This removes one of the last reasons for using the 32 bit version of fre:ac on modern 64 bit Windows systems.

Besides working on that, I have incorporated the Lancer patches into the Ogg Vorbis encoder. The patches rewrite certain algorithms in SSE/SSE2 to speed up conversions by approximately 40%. Some other encoders are now compiled using further optimized compiler options to speed them up a little compared to the October snapshot as well. For example, compiling LAME with -mfpmath=sse speeds up the 32 bit version by 6% on my system. The 64 bit version uses SSE by default, so there's no further speedup for that one.

Another thing I would like to have in the next snapshot is support for verification of conversions. This will allow validating lossless encodes and possibly pave the way for CD rip verification in fre:ac. I'll probably have more news on this in November or December.

While analyzing and comparing conversion speed of different fre:ac releases, I discovered an issue with the MP3 decoder component of fre:ac 1.0.22. The bug can make fre:ac crash when converting MP3 files to other formats and I think it's responsible for most of the crashes people still experienced with fre:ac 1.0.22 and earlier versions. I have a fix for this and will probably release fre:ac 1.0.23 in November. Recent snapshot versions are not affected by that problem.

This closes this months issue. I'll probably give an estimate on the next snapshot's release date next month.

I posted this request in the PowerMac forum of MacRumors.com earlier today, but they immediately deleted the post and permanently banned my account. I'm surprised and quite disappointed by their harsh behaviour. Seems like they are not willing to help open source developers support their platform.

As you'll probably know, I added support for parallel conversions in the 20140921 snapshot. Speedups were great on the computers I tested on and users reported similar results on their systems. However, I have not been able to test the parallel conversion mode on multi-processor PowerMacs, yet. I only have a single-processor G4 PowerBook to test the PowerPC version on, so I'm now looking for people who could give it a try on a dual/quad PowerMac. Results for a quad G5 would be especially interesting.

If you would like to help, please use the 20141005 release for your tests. Note that you will need at least OS X 10.5 Leopard for fre:ac to work. Additionally, you'll have to enable parallel conversions on the Resources page of the configuration dialog, as it is still experimental and disabled by default. Also note that parallel processing is supported for file conversions only, not CD ripping (unless you have multiple drives).

Please post your results in the SourceForge forum or send them to info@freac.org. Thanks to everyone who participates!

Here's the September issue of the fre:ac development status update.

The biggest news this month is the release of fre:ac snapshot 20140921 with experimental support for parallel conversions. Surprise!

Admittedly, this actually was not planned that way. While I had plans to add support for parallel conversions in a future release after fre:ac 1.1, I had a very complex architecture in mind. The decoding and encoding would run in different threads exchanging data using a ring buffer. However, building it that way would have taken several months, so I planned to release fre:ac 1.1 without it.

Then, about a month ago, I suddenly had the idea of doing it differently: Why not simply take the existing conversion code, but run several parallel instances of it - each processing a part of the joblist? Thought about it, started coding and had a working proof of concept after one day. About a week later, it was good enough to consider inclusion in the September snapshot as an experimental option - which finally came to be.

The originally planned solution would probably give an additional 1-5% speedup for single file conversions, but this is available now and the original ideas can still be implemented on top of the current solution at a later date.

When activating parallel mode in the configuration dialog, you can select how many CPU cores and thus parallel conversion threads should be used. The automatic option will use all the physical cores, leaving virtual cores alone, so you can still work while fre:ac is running in the background. You can move the slider to enable the use of virtual cores or set it to less than the total number of cores to avoid 100% CPU use on systems without hyper-threading support.

But enough of the talk, lets look at the numbers, which are really great! The charts show the time taken to convert the album Blonde by Coeur de Pirate from FLAC to MP3 on Windows 7 and OS X Mavericks using default settings (click to enlarge):

Mostly thanks to the use of more agressive optimization options for compiling the codecs, even the non parallel mode is roughly 30% faster than fre:ac 20140609 on my development system. In parallel mode, there's an additional speedup of 4.4x when using all 8 threads.

Truly groundbreaking are the numbers for OS X. Thanks to additional optimizations of the OS X code, non-parallel fre:ac 20140921 is more than 4x faster than 20140609 on my Mac. Using parallel mode even speeds it up 18x vs. the June snapshot. Even on my old PowerBook G4 with only one CPU core, fre:ac is actually usable now.

Where there's light, there must be some shadow, though, so the bad news is that some problems have been found in the September snapshot that I'm currently fixing. Most notably, decoding Vorbis files in parallel mode produces garbled audio and the 32 bit Windows version of fre:ac immediately crashes on some CPUs (definitely on Athlon 64, but possibly others as well) when trying to use the LAME, FLAC, Vorbis, Opus or Speex codecs. I will release a new snapshot in early October to address these issues.

Originally, I wanted to write the September status update today, but something came in my way...

I'm a little enraged right now! Why? I'm developing fre:ac as a hobby project in my free time. I don't want to make big money with it and so I'm ignoring the mails that come in every other week asking if I wouldn't want to trick my users into messing up their computers for a dollar each by bundling with adware. No thanks, I don't! But lately, more and more download sites are doing exactly this. They are wrapping my software (and others') in their own adware downloaders ruining its reputation.

It started with CNET Download.com a few years ago. They wrapped every download into an adware installer that would try to install toolbars and other foul stuff. Of course, they didn't ask or even inform the software developers, why should they? Soon an uproar went through the IT community and media and forced them to retract a bit. When I learned about it through a German IT news site, they had already ceased to distribute open source software like fre:ac that way. Ultimately, they made the adware downloader an opt-in program.

But the devil was out of the box already. Other download sites started doing the same. Again, without asking the developers. I imagine they might be a little masochistic like "Hey, CNET did this and got beaten heavily! Let's do it too!".

Today I just found one more of those sites! But wait, it's an exceptional one! Exceptionally bad!

I stumbled on this thread on a German message board helping people to get rid of malware on their systems.

The user explains that he downloaded fre:ac from GIGA.de, a site which he thought was trustworthy (I did too!). Then started the installation, clicked away the adware offers (What?) and still got a malware warning from his virus scanner (WTF?). His browser start page was modified and he fears that some malware has been installed on his system. He then concludes with the warning "Finger weg vom fre:ac-Dreck!" which translates to "Hands off that fre:ac shit!".

I had to check that! I'd never bundle fre:ac with any malware! I went to GIGA.de, looked for fre:ac and started the download. The file offered was named fre_ac-audio-converter-lnstall.exe and had a size of just under 1 MB instead of the usual 7 MB for the regular fre:ac 1.0.22 download. Also note that it ends in lnstall.exe, not install.exe (the first letter is a lower case L, not an I). Looks like they are trying to obfuscate something by that already. Sneak under the radar of some malware scanners? I don't want to know!

Running the file, it brings up an installer dialog that looks unsuspicious at first glance. Note how it says "fre:ac audio converter Setup" and "Welcome to the fre:ac audio converter Installation Assistant" just like it was an official fre:ac installer. You almost want to click next to get to the installation options.

But look more carefully! See the blue buttons on blue background at the left? Yes, blue buttons on blue background! I'm still baffled when writing those words hours later! Designed to be overlooked. Also, this thing wants to install not one, not two, no, three adware additions at once. An Amazon Icon, a shopping application called Sparpilot and Securita Scout, which sounds like it might be some sort of scareware.

Everything is laid out in such a way that many users would continue without actually noticing what's happening. Remember that there is no hint whatsoever that this is a 3rd party adware installer. I didn't click next, but users who do will blame me and the fre:ac project for the malware they get.

Of course, fre:ac is not the only download they wrap up so nicely. I found popular open source software like Firefox, VLC or GIMP equipped with the same installer. Even iTunes, Chrome and Skype are bundled with it. I wonder if Apple, Google and Microsoft will find that funny when they find out.

Now you might think that's probably a niche site with next to no users, but no! GIGA.de is well known in Germany; Alexa ranks them at #173 in this country. Also, GIGA generally has had a good reputation here. Looks like they are now gambling it away, though.

The only good thing today: They quickly removed the wrapper for the fre:ac download after I asked them to.

After all this, I looked for other sites wrapping fre:ac in dubious downloaders and found three: CHIP.de, Softonic and BrotherSoft. Unlike GIGA though, they are not playing hide and seek and are making it obvious that it's their own installer running. They also don't use blue buttons on blue background (no, I still can't get enough of that). I still asked them to deactivate their downloaders for fre:ac and expect that they'll do so in the next few days.

If you know other sites that are offering fre:ac bundled with adware, please send a mail to support@freac.org.

Here's the fre:ac status update for August, which was a very productive month for fre:ac development.

Besides great improvements for the OS X version, many smaller things that will benefit all users have been added, improved or fixed in the past four weeks.

The new features include the ability to preview output file names in the joblist (the corresponding column can be enabled in the configuration dialog), displaying cover art of the currently selected track in the title info area and tooltips in case text is cut off in drop down boxes and lists. See the screenshot to the right for a preview of the output file name and cover art features.

I also took a look at conversion performance and compiled optimized versions of all codecs for all supported operating systems. The new codecs will use only one CPU core, but still be slightly faster than the multicore versions used on Windows before, thanks to improved optimization in modern compilers. In addition, using only one core will make it easier to add support for true parallel conversion in a future release.

Finally, I reworked the internationalization system to enable language-specific punctuation and support for translating units of measurement. Language-specific punctuation means that you'll have to change only one place in the translation file to enable the use of language-specific colons or brackets (as used in Asian languages for instance) everywhere in fre:ac starting with the next snapshot. Similarly, translating units of measurement adds the ability to replace units like kbps or ms with localized versions (e.g. in Cyrillic script) throughout the application.

Regarding OS X, fre:ac now supports the common menu bar. This works transparently to fre:ac by automatically mapping the menu widget to Cocoa menus and menu items on-the-fly in the smooth class library. The toolbar icons are aligned at the center of the window in this case to make the interface more balanced with the menu bar gone. The screenshot to the right shows this new layout.

After finishing common menu bar support, I took a look at the remaining issues on OS X, namely performance and stability problems. I fixed lots of them, so the next snapshot will be about three to four times faster, have a more responsive user interface and will run much more stable than the 20140609 release.

You may have heard that Apple will change the signature requirements with OS X 10.9.5 and 10.10. The 20140609 snapshot will cause a Gatekeeper warning on those new OS X versions. I'm already using the required V2 signatures in my testing, though, and they will be used in the next snapshot which should be out before the new OS X releases.

For everyone who would like to compile fre:ac on their own, the next release will print detailed instructions including a list of dependencies when running configure to ease and aid the build process.

Unrelated to the fre:ac development versions, but still worth mentioning, I put together a translation kit for fre:ac 1.0.22. This makes translating fre:ac to another language easier by having all the necessary ressources in one archive together with an explanation of how to work with them. If you think you could contribute a new translation for fre:ac or update one of the outdated translations listed on the translation status page, please have a look at the translation kit!

Closing this months issue with more good news, the release of the next snapshot in September is now definite. It will be out in three or four weeks.

In the past month I mostly concentrated on the release of fre:ac 1.0.22, the latest service release for the stable release series. It contains codec and translation updates as well as some bug fixes. The patch that brought clear UI text to high DPI displays on Windows 8 (as explained in the 04/2014 status update) is applied in 1.0.22 as well.

Of course I also worked on the development version, just not as much as usually. I have implemented libsndfile based output to replace the Wave File output component. This will allow you to create AIFF, Wave, Wave64 and RIFF 64 files (among others) using fre:ac starting with the next snapshot.

I also started implementing joblist sorting. You will be able to sort the joblist by artist, title, length and other criteria by clicking on the column headers.

No work on the Linux or OS X versions this month, so there's not much to talk about regarding those. There still are some stability problems on these systems that need to be addressed before the next snapshot release.

Speaking of it, the next snapshot will probably be ready in September.