CentOS + K3b + MP3 + Audio CD defeated me

Updated: August 17, 2015

Bear with me. There's a chance this article's problem has a trivial solution, and I'm just being severely challenged. But the story goes as follows, several months ago, one of my readers contacted me, asking how one would go about creating audio CD in CentOS. I agreed to help, and promised a full tutorial for the wider audience. Which is what prompted this article.

However, it is not often that I utterly fail in my mission. But writing about my Linux failures is just as important as any other successful tutorial. One, I have recommended CentOS plenty in the past, and so it wouldn't be fair to you if I were to hide away the distro's ugly points and problems. Two, this is an important message to the community, and hopefully, this little article will prompt the right kind of reaction. Now, let's proceed.

The problem 

When you launch K3b, you will most likely see this evil, foreboding message:

Missing audio codecs

It is very confusing and possibly misleading. Indeed, in my case both LAME and MAD decoders were installed, but K3b was not using them. Some additional software packages were missing. And this is where the hunt begins.

Solution (or rather not)

If you start searching, you will soon get lost in a sea of recommendations and options, none of which will give you the desired ability to burn MP3 files to audio CD without having to convert them. Hint, in general, conversions work relatively well, and that's an easy alternative, although not necessarily achievable on CentOS. Do read on.

Basically, you need packages called k3b-extras, k3b-extras-freeworld or k3b-codecs. Any one will do. However, as we speak, none of these are available for CentOS 7. They are available for CentOS 6. This means that there's no simple, supported way of getting the desired functionality.

You may think that there's a problem with your setup. But if you've installed extra repositories, and followed my pimping articles, then you already have all that is required for fun. Well, except the K3b stuff. But still, just in case, make sure you have the following set of packages installed:

yum install libmad lame

Manual K3b codecs download

The following may work, but it's a risky option. You can download the codecs RPM from the Web, from one of the many available repositories. You can then try to install the file, but it will conflict with the default version. To wit, we fail:

rpm -Uvh k3b-codecs-2.0.80.git20131118-1.1.x86_64.rpm

warning: k3b-codecs-2.0.80.git20131118-1.1.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID 1abd1afb: NOKEY

error: Failed dependencies:

k3b = 2.0.80.git20131118-1.1 is needed by k3b-codecs-2.0.80.git20131118-1.1.x86_64
libqt4-x11 >= 4.7.3 is needed by k3b-codecs-2.0.80.git20131118-1.1.x86_64

A hack that might work is to unpack the RPM archive using rpm2cpio:

rpm2cpio ../k3b-codecs-2.0.80.git20131118-1.1.x86_64.rpm |
cpio -id

Then, in the extracted directory, you will find several shared libraries, located under /usr/lib/kde4 or /usr/lib64/kde4, which you can copy into the correct path on your system. Once you relaunch K3b, it might find the new libraries and start using them. However, this is rather tricky, because you may end up with weird behavior, incompatibilities, and the packages will not be patched during system updates. You can try the same thing with CentOS 6 packages, but again, they might not really work. Most likely not.

cd usr/lib64/kde4/ ; ll

-rwxr-xr-x. 1 root root 31400 Feb 13 14:18 k3bffmpegdecoder.so
-rwxr-xr-x. 1 root root 35840 Feb 13 14:18 k3blameencoder.so
-rwxr-xr-x. 1 root root 43984 Feb 13 14:18 k3bmaddecoder.so
-rwxr-xr-x. 1 root root 68968 Feb 13 14:18 kcm_k3blameencoder.so

cp * /usr/lib64/kde4/

Manual K3b compilation

This is an option, too. Unfortunately, a bad one, because cmake won't work well. If you have the strength to debug and such, be my guest. I am giving up.

-- Detecting C compiler ABI info - done

CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found. Please set CMAKE_CXX_COMPILER to a valid compiler path or name.

CMake Error at /usr/share/cmake/Modules/FindKDE4.cmake:98 (message):

ERROR: cmake/modules/FindKDE4Internal.cmake not found in
/root/.kde/share/apps;/usr/share/kde-settings/kde-profile/
default/share/apps;/usr/share/kde4/apps
Call Stack (most recent call first):
CMakeLists.txt:52 (find_package)

Conversion

Several programs that may work in converting MP3 to WAV are mpg123 and ffmpeg. In my case, neither of these programs accomplished the task. The former simply created tiny, meaningless files, and the latter refused to work, even with the optional -acodec flag. Something that always used to be so trivial and even pleasant, right. But when it goes wrong, it goes horribly wrong.

You may also consider the k3b-pacpl converter, but there's no direct download for CentOS, and you will have to compile manually. This also means installing several extra packages from CPAN. While the provided installer script does that, the installation will fail regardless:

checking for perl module Audio::Scan... no
checking for perl module Audio::FLAC::Header... no
configure: error: ERROR: One or more of the required modules could not be found. See extra/mod-install.sh or extra/mod-install-ubuntu.sh

Conclusion

I still believe CentOS is a very practical, modern and elegant operating system that has a lot of potential in the home environment, too. It's fast and stable, and those are very important attributes. But then, not everything works out of the box, and sometimes it's virtually impossible to accomplish certain tasks. Audio CD generated from MP3 files in K3b would be a classic example.

In fact, CentOS 6 is preferable when it comes to music manipulation. It's not as good if you need Steam or Chrome, but MP3-wise, it wins over the latest EL7-based family. It's been a while since CentOS 7 was released, and this kind of thing ought not to happen. Either there should be full and seamless support for all the distro's subsystems and proprietary fun or not at all. We definitely don't need a half-hope half-despair state.

Anyhow, I hope that various developers and maintainers of third-party repositories will sit down, decide on what ought to be supported, and then converge on the widest assortment of packages that provides the necessary desktop functionality. At the very least, provide the same level of support that existed in CentOS 6, because people expect things to keep working and not just arbitrarily break, which is the case here. Otherwise, Kubuntu and friends sure offer a far more varied and easily accessible experience. From my end, to my readers, apologies. I sucked monkey balls today. That would be all.

Cheers.