fix ffmpeg concatenation call in merge_into_mp3

[holyspiritomb]

Short explanation:

The concatenation of downloaded mp3 tracks into one mp3 file without reencoding, a part of the merge process, suddenly became extremely slow for me today, when it normally takes a few seconds. Downloaded libby mp3 files that have an embedded cover image appear to be the culprit.

This pull request adds -vcodec copy to the ffmpeg command that's called during that step of an audiobook merge (in the merge_into_mp3 function), which fixes the issue.

Long explanation:

I encountered strange behavior where, if I told odmpy to merge, regardless of merge format, concatenating the downloaded mp3 files into one mp3 file would show a speed of about 100x and then drop consistently until it was less than 1x. After about 20 minutes, the speed had dropped to 6x and the concatenation had only processed an hour of audio. Normally this concatenation step takes less than a minute.

The ffmpeg output, when I tested using only the ffmpeg call that odmpy was making, seemed to indicate that ffmpeg was interpreting the command to copy the audio correctly, but it was also interpreting embedded cover images in the input mp3 files as a stream to be reencoded. I changed the ffmpeg call so that it just copies any such stream instead of reencoding.

[ping]

Thanks for the PR.