Switch from Python-Audio-Tools to Pydub and m4a support

[twinoflink]

Fixes #12

The old library used for transcoding the files to .mp3 didn't support .m4a files.
Pydub relies on ffmpeg and is capable of transcoding all of the "old" file formats and others like e.g. .m4a.

Furthermore support for copying the tags from a m4a file to the transcoded mp3 was added.

[coveralls]

Coverage remained the same at 100.0% when pulling 400fd8b on twinoflink:pydub into 16e219b on fetzerch:master.

[twinoflink]

I also added a Python 3.9 job to the travis config

[fetzerch]

Sorry that I didn't look at this earlier. I'm not against changing to pydub in general. Given that python-audio-tools still doesn't provide a proper installation via pip. Unfortunately we'd first have to find a proper solution for replaygain, and in a few tests that I've performed so far, the new pydub based code is significantly slower. Transcoding ~250 files takes 3:02 now and 2:27 before. That certainly might be caused by different encoder settings, but it's still sth to investigate.

BTW: Did you try m4a with python-audio-tools? The homepage lists it as a supported format - it might require some additional libraries (http://audiotools.sourceforge.net/install.html) though.

I'll split out some of your changes like the pylint fixes into a different PR so that we can already apply them independently.

[fetzerch]

The idea of the two modes replaygain and replaygain-album is to the read the replaygain info from the existing metadata and then adjust the volume in the output file accordingly. This avoids having to readjust the volume all the time when using players that don't support reading those replaygain tags.

I played around with pydub but couldn't find an easy way to achieve the same:

• Your code just writes 2 of the 4 replaygain tags back to the output file.
• Adding "-af", "volume=replaygain=track" here doesn't work, because the temporary wav input file doesn't have the replaygain metadata (-metadata only sets the data for the output file).
• Adding parameter=["-af", "volume=replaygain=track"] to AudioSegment.from_file doesn't work either because the parameters are added to late to the ffmpeg call (https://github.com/jiaaro/pydub/blob/master/pydub/audio_segment.py#L760-L762, they would have to go before the output file -f wav)

[twinoflink]

Thank you for your reply and for merging at least parts of the code.
The problem with the .m4a container is that many files use aac or somthing similar as the audio codec which isn't supported by the standard pydub installation. The page you mentioned (http://audiotools.sourceforge.net/install.html) lists the required libraries but I wasn't able to install any of them reliably which is why I looked for a solution which uses ffmpeg.
Regarding the transcoding speed: I don't know why this happens. I included an option to select between constant bitrate and variable bitrate and an option to select the desired quality. I think that this might be something that results in the different speeds.
Replaygain: I am sorry for the problems but I tried to implement it as good as I could because I wasn't able to find a good documentation on the "standard" or any program which I could have used for testing the metadata.

[fetzerch]

What Linux distro do you use? For ubuntu https://packages.ubuntu.com/focal/audiotools lists faad as recommended package. I could give it a try with the sample files you created.

Regarding the speed it would be interesting to see if that's caused by pydub, or by ffmpeg and if it's slow in the decoding to wav or in encoding to mp3.

For replaygain: No need to be sorry, this is no easy topic at all, especially because things aren't that well documented. I'm also not sure yet how this works in ffmpeg. The idea is to precalculate gain/peak (for the whole album, and for the single track) and add this info to the metadata. Supported players read this information and dynamically adapt the volume. In sync_music, we'd need to apply the volume change when transcoding the file. I also don't have a nice way of testing it. I just opened the output file in audacity. I'm sure replaygain could be tested automatically. We'd need to 'just' recalculate the replaygain data for an output file (for example with ffmpeg -i <file> -af replaygain -f null /dev/null) and see if it matches an expected value.

Would you have time/interest to look into any of these in more depth? I have to admit that I don't have a lot of sparetime at the moment, can't promise if/when I'd get to it. An intermediate solution could be to get aac/m4a to work with audiotools.