Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: linux audio tools recommendations 2015/09 (Read 29147 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

linux audio tools recommendations 2015/09

Reply #25
^ I can only suggest the same. I've tried many distributions and all of them are plagued by various issues and outdated software to some degree. I have also tried gentoo, but I spent more time compiling than using the stuff I compiled. Arch is a very nice balance of up-to-date software and effort involved into setting it up and maintaining it. The documentation is superb (I've even seen many other distributions link to arch's wiki for troubleshooting), and I had no problems installing it by just following the beginner's guide. The forums are also insanely helpful. It's the only distribution that managed to finally make me switch to linux. You have the official repositories where you get binary packages from, and also the AUR, user created packages you have to download and compile before installing. The compiling process is a one-liner, and you get access to packages based on git snapshots for bleeding edge software. The binary packages are updated via the package manager, while AUR packages are updated by the user. Both types of packages are installed and removed by the package manager, making it a very well working system in my eyes.

Just don't make a mistake of taking the "installer" route, aka picking a distribution based on arch - it comes with the same problems as other distributions usually. If you configure something yourself, you will know where to find it when something breaks. It may be more effort at the start, but it pays off rather quickly.

What do you mean by "depending on the playback mode"?

There is a plugin for fb2k (actually, integrated now) as well as one for deadbeef that allows you to assign which mode to use, for example use track gain once you change to shuffle, or album gain once you change to linear playback mode.

Thanks for the explanation (both of you), it doesn't seem quite useful in my setup. It could be interesting for listening via my phone at home, getting the music streamed via http in a format my phone won't decode natively, but I usually listen via my PC when I'm at home, so that isn't really that useful.

linux audio tools recommendations 2015/09

Reply #26
i must admit, i dont like the softwarecenter at all. many versions of tools are simply outdated, missing great new features.


synaptic is more of a systems administrator experience, and less of shopping mall experience. But, unless you seek out the ppas, or even download source code and compile it (believe it or not, this is not necessary difficult, even for a non-programmer; sometimes it just takes a couple of commands and all is done) you are still only getting the "official" versions. The positive side of that is you can fairly certain they will be absolutely compatible with your version.
The most important audio cables are the ones in the brain

linux audio tools recommendations 2015/09

Reply #27
^ I can only suggest the same. I've tried many distributions and all of them are plagued by various issues and outdated software to some degree. I have also tried gentoo, but I spent more time compiling than using the stuff I compiled. Arch is a very nice balance of up-to-date software and effort involved into setting it up and maintaining it. The documentation is superb (I've even seen many other distributions link to arch's wiki for troubleshooting), and I had no problems installing it by just following the beginner's guide. The forums are also insanely helpful. It's the only distribution that managed to finally make me switch to linux. You have the official repositories where you get binary packages from, and also the AUR, user created packages you have to download and compile before installing. The compiling process is a one-liner, and you get access to packages based on git snapshots for bleeding edge software. The binary packages are updated via the package manager, while AUR packages are updated by the user. Both types of packages are installed and removed by the package manager, making it a very well working system in my eyes.

I don't really see the advantage. For one, distros like Ubuntu, Fedora, and openSUSE allow me to add repos which contain the latest and greatest/bleeding edge software. And I get fully-functional packages, I don't have to compile anything.

In my experience, the user/third-party repos cover pretty much everything. Nowadays, it happens no more than once or twice a year that I build stuff myself using the old school ./configure - make - make install way.

For another, 99% of the time, I want stability, not the bleeding edge. I've had enough pain back in the day when even Debian stable was broken in some way, missing support for some of my hardware or whatever. So for the most part, I'm happy that my distro just works out-of-the-box, no constant fiddling required.

linux audio tools recommendations 2015/09

Reply #28
You configure stuff yourself and don't rely on someone doing it for you and hoping they will do it right. I can't count the times I was trying to get a feature to work and failing to do so, just because somewhere deep in the system I had no idea about, another option was pre-configured totally wrong. You also seem to think bleeding edge is unstable, and stale releases are stable. You are wrong. I'm now running arch for more than a year, and in that year, I only had a package break once. I simply downgraded it and waited for it to be fixed, which was the case as soon as it was fixed upstream. Now imagine being on a "stable" distribution - you're often stuck with a broken package until the next release cycle.

Another thing I often had on *buntu is that once I needed additional software not in the repos, I had to get a ppa that had it - fine and dandy, except that ppas required other ppas that updated core packages to a recent version, or required enabling the unstable repo, or even worse, there was no ppa for the particular library and you were forced it via configure/make/install. None of that on Arch. The binary packages are up to date, so if you need a new lib, the dependencies are satisfied. Should there be no AUR package, you can relatively easily make your own - the main advantage is that even external packages are installed via your package manager, so you never lose track of the respective files, guaranteeing that uninstalling the package will actually remove all traces of the software.

Also, while there seem to be "git" ppas, you are still relying on someone maintaining those. With arch, you have the PKGBUILD file that acts as a script to build the package, and the actual source is pulled directly from the git repo - you control when you get the newest version, not the ppa maintainer (if there is one).

linux audio tools recommendations 2015/09

Reply #29
I must agree to the comments on Arch Linux with a big grin on my face - Arch linux made me finally switch to linux too.

I'd like to ask the mpd users in here whether you have been able to use replaygain on m4a (itune) files too? Out of box, it doesn't work because replaygain is not officially specified for m4a/mp4 files (?). At least that was a dev's answer on mpd's bug tracker, who rejected my bug report (Link. It's kind of annoying, cause I don't like to transcode the m4a files to a format which supports replagain tags.

linux audio tools recommendations 2015/09

Reply #30
I'd like to ask the mpd users in here whether you have been able to use replaygain on m4a (itune) files too? Out of box, it doesn't work because replaygain is not officially specified for m4a/mp4 files (?). At least that was a dev's answer on mpd's bug tracker, who rejected my bug report (Link. It's kind of annoying, cause I don't like to transcode the m4a files to a format which supports replagain tags.

As far as I know, ffmpeg(libavformat) can read/export custom iTunes metadata including replaygain_* and iTunSMPB from April 2014, and mpd seems to use ffmpeg as catch-all decoder for quite many formats including m4a. Therefore I don't know why they can't support it.
However, does mpd support gapless playback of AAC/m4a in the first place? I know that ffmpeg doesn't, and mpd also doesn't seem to do something special for it. So, it might be useless for m4a playback even with replaygain support.

linux audio tools recommendations 2015/09

Reply #31
I'd like to ask the mpd users in here whether you have been able to use replaygain on m4a (itune) files too? Out of box, it doesn't work because replaygain is not officially specified for m4a/mp4 files (?). At least that was a dev's answer on mpd's bug tracker, who rejected my bug report (Link. It's kind of annoying, cause I don't like to transcode the m4a files to a format which supports replagain tags.

As far as I know, ffmpeg(libavformat) can read/export custom iTunes metadata including replaygain_* and iTunSMPB from April 2014, and mpd seems to use ffmpeg as catch-all decoder for quite many formats including m4a. Therefore I don't know why they can't support it.
However, does mpd support gapless playback of AAC/m4a in the first place? I know that ffmpeg doesn't, and mpd also doesn't seem to do something special for it. So, it might be useless for m4a playback even with replaygain support.


I reopened the bug report, hoping that cirrus won't screw it up once again.

Do you have any (official) specification for iTunes metadata? I spent some time using google for it, but couln't find anything.

linux audio tools recommendations 2015/09

Reply #32
Do you have any (official) specification for iTunes metadata? I spent some time using google for it, but couln't find anything.

Well, there's a PDF named "iTunes Metadata Format Specification" by Apple, but I cannot find it now on the Internet.
I don't think the spec is not important anyway. As far as I can see, they don't even have their own MP4 parser. What's the use of spec then? They just let libavformat parse MP4 files. So, important thing is that they should be able to retrieve replaygain tags from libavformat if it is not too old.
Anyway, I'm not interested in it when it cannot even do gapless playback. Unusable.

linux audio tools recommendations 2015/09

Reply #33
Do you have any (official) specification for iTunes metadata? I spent some time using google for it, but couln't find anything.

Well, there's a PDF named "iTunes Metadata Format Specification" by Apple, but I cannot find it now on the Internet.
I don't think the spec is not important anyway. As far as I can see, they don't even have their own MP4 parser. What's the use of spec then? They just let libavformat parse MP4 files. So, important thing is that they should be able to retrieve replaygain tags from libavformat if it is not too old.
Anyway, I'm not interested in it when it cannot even do gapless playback. Unusable.


Maybe you can drop a reply if you find the spec.

Do you know if there is a bug report for the lack of gapless playback on m4a/mp4 files? This means that basically any audio player using ffmpeg can't play m4a gapless?

linux audio tools recommendations 2015/09

Reply #34
Do you know if there is a bug report for the lack of gapless playback on m4a/mp4 files? This means that basically any audio player using ffmpeg can't play m4a gapless?

Any? No. It is possible (fb2k is an example, but it uses only part of libavcodec and not libavformat).
However, it is not achieved by ordinary usage of libavformat / libavcodec. Therefore, I guess *most* of ffmpeg based player doesn't play m4a gaplessly.

linux audio tools recommendations 2015/09

Reply #35
I reopened the bug report, hoping that cirrus won't screw it up once again.

Do you have any (official) specification for iTunes metadata? I spent some time using google for it, but couln't find anything.


Have you tried the latest git version?

linux audio tools recommendations 2015/09

Reply #36
WINE actually gives unix like system a stable API which they traditionally lacked [minus non-free ones like osx / android]. I ran a tweaked debian lenny system years ago and EAC, Foobar, Burrn and most other win32 tools ran fine.

linux audio tools recommendations 2015/09

Reply #37
WINE actually gives unix like system a stable API which they traditionally lacked [minus non-free ones like osx / android]. I ran a tweaked debian lenny system years ago and EAC, Foobar, Burrn and most other win32 tools ran fine.

yes, you are right. it is only eac and cuetools that could not be persuaded to start / work - i am still a novice concerning linux/wine.

some helpful hints on a foolproof setup are also very welcome

linux audio tools recommendations 2015/09

Reply #38
I don't know about EAC, but CUETools ran well once I installed their dependencies: .NET Framework 2.0 SP2 and Visual C++ 2008 runtimes.

linux audio tools recommendations 2015/09

Reply #39
WINE actually gives unix like system a stable API which they traditionally lacked [minus non-free ones like osx / android]. I ran a tweaked debian lenny system years ago and EAC, Foobar, Burrn and most other win32 tools ran fine.

yes, you are right. it is only eac and cuetools that could not be persuaded to start / work - i am still a novice concerning linux/wine.

some helpful hints on a foolproof setup are also very welcome



You might want to try the last  0.99x EAC. I had it working perfect in wine 1.0 and 1.1.25 years ago.

https://appdb.winehq.org/objectManager.php?...n&iId=10017

linux audio tools recommendations 2015/09

Reply #40
out of curiosity, is wine + net framework x.x the better solution than wine + mono?

right now, i have installed net framework 2.0 sp2, following this guide (installation by using 'winetricks' script):

https://appdb.winehq.org/objectManager.php?...on&iId=3754


what is the most straightforward method to install the visual c++ 2008 sp1 redistributable package?

linux audio tools recommendations 2015/09

Reply #41
^ As all runtime packages, via winetricks. Just install the vc2008 package.

linux audio tools recommendations 2015/09

Reply #42
I don't know about EAC, but CUETools ran well once I installed their dependencies: .NET Framework 2.0 SP2 and Visual C++ 2008 runtimes.


.NET Framework is something that I heaved a sigh of relief to have left behind. There is no way that I would want it back
The most important audio cables are the ones in the brain

linux audio tools recommendations 2015/09

Reply #43
I don't know about EAC, but CUETools ran well once I installed their dependencies: .NET Framework 2.0 SP2 and Visual C++ 2008 runtimes.


.NET Framework is something that I heaved a sigh of relief to have left behind. There is no way that I would want it back



Really  what exactly is wrong ?  For an end user its just there preinstalled (in win 7 +) , most end users know nothing don't care for it and just run their applications.  In linux you have a gazillion types of 'frameworks' , libraries etc much worse than windows and no one complains [usually] oh except kdelibs.

linux audio tools recommendations 2015/09

Reply #44
I run Ubuntu Studio v14.04.3 with Wine v1.70.50 and Foobar2000 works pretty much just fine in it.  So you might have some decent luck as well.  But yeah, DeaDBeeF is okay, but not as customizeable.
Be a false negative of yourself!

linux audio tools recommendations 2015/09

Reply #45
However, using wine you have some (measurable) decrease in sound quality, as music can not be played natively on the audio harwdare. Instead, it needs to additionally pass resampling within the wine layer. At least that's what it was some time ago, when I invesitigated whether foobar with wine was an acceptable alternative to native linux players.

linux audio tools recommendations 2015/09

Reply #46
I reopened the bug report, hoping that cirrus won't screw it up once again.

Do you have any (official) specification for iTunes metadata? I spent some time using google for it, but couln't find anything.


Have you tried the latest git version?


Not yet, I tried to but I had trouble with my alsa output device using the AUR package mpd-git. Do you think it's fixed in trunk (maybe you can post the corresponding commit log)?

Edit: Sorry for double post, I thought that posts were combined.

linux audio tools recommendations 2015/09

Reply #47

.NET Framework is something that I heaved a sigh of relief to have left behind. There is no way that I would want it back



Really  what exactly is wrong ?  For an end user its just there preinstalled (in win 7 +) , most end users know nothing don't care for it and just run their applications.  In linux you have a gazillion types of 'frameworks' , libraries etc much worse than windows and no one complains [usually] oh except kdelibs.


The five minute installs that then say you have the wrong .00000-something version of damned .NET and spend ages downloading and installing it. Then the Windows .NET updates, that takes, hours, days or even weeks (hyperbole alert). Pain in the .NECK.

If this is out-of-date, so be it. My last experience of Windows (apart from being a visitor in the houses of others) was XP, and I sincerely hope it stays that way.

LIbraries, in *nix are equivalent to DLLs of the MS world. The old thing (this, I think (and hope) is out of date) is that some programmer included his own version of a DLL, which broke other stuff. That never really happened in the *nix world, because people would be shot if they did it. thus... natural selection .

The most important audio cables are the ones in the brain

linux audio tools recommendations 2015/09

Reply #48
The five minute installs that then say you have the wrong .00000-something version of damned .NET and spend ages downloading and installing it. Then the Windows .NET updates, that takes, hours, days or even weeks (hyperbole alert). Pain in the .NECK.

If this is out-of-date, so be it. My last experience of Windows (apart from being a visitor in the houses of others) was XP, and I sincerely hope it stays that way.

Yeah, it is. Haven't had any problems with .NET on vista through 10. I do remember stuff you describe happening on win XP, though, but then, I never got what people saw in that OS anyway...

But yeah, DeaDBeeF is okay, but not as customizeable.

I don't know, customizable enough for me

linux audio tools recommendations 2015/09

Reply #49

.NET Framework is something that I heaved a sigh of relief to have left behind. There is no way that I would want it back



Really  what exactly is wrong ?  For an end user its just there preinstalled (in win 7 +) , most end users know nothing don't care for it and just run their applications.  In linux you have a gazillion types of 'frameworks' , libraries etc much worse than windows and no one complains [usually] oh except kdelibs.


The five minute installs that then say you have the wrong .00000-something version of damned .NET and spend ages downloading and installing it. Then the Windows .NET updates, that takes, hours, days or even weeks (hyperbole alert). Pain in the .NECK.

If this is out-of-date, so be it. My last experience of Windows (apart from being a visitor in the houses of others) was XP, and I sincerely hope it stays that way.

LIbraries, in *nix are equivalent to DLLs of the MS world. The old thing (this, I think (and hope) is out of date) is that some programmer included his own version of a DLL, which broke other stuff. That never really happened in the *nix world, because people would be shot if they did it. thus... natural selection .


You must be joking - yes its very out of date and also the winxp problem (it became very stable from sp2). That DLL thing is from win3.x / 9x days. Like 20 years ago where the multi versions went into c:\windows and broke apps. Every app in modern days uses system dll and if not then its own DLL goes in \program files\appname or a portable folder - NO clashes whatso ever and can have many different versions of the same app and different libs.

Its actually unix thats screwed in this regard (for desktop use). You cannot easily run multiple versions of libs say - Qt3, Qt4 ,Qt5  /different versions of GTK + etc since all goes into /usr/bin , /usr/lib and multi versions will break everything. Try running GTK1 apps these days, or KDE2 or even 3 - where are these libs? . they cannot even be compiled properly most likely without something breaking. Try a new app - oops your GTK+, pango etc is too old etc. You cannot have multi versions . Even if you did manage to install a backport of the libraries something else that depended on the old one will cease to run.  In windows you want to run a modern gtk or qt app and older ones  - no problem . All needed dependencies go into \program files\appname..  In linux each of the gazillion libs go into ONE SYSTEM folder and you cannot upgrade / downgrade them sanely because almost every future version of these gazillion libs will be binary / api incompatible with the past version.