youtube-dl skips post-processing for M4As

[Kaos-Industries]

Hey there.

First of all, thanks for a great program, youtube-dl is the only program on the market I've come across that allows me to extract the audio from my huge YouTube playlists and convert them to M4A ready to be put on my phone.

The problem I'm currently having is that after extracting the audio, ffmpeg skips the post-processing, leaving me with the original-quality audio files rather than converting them to the 192k bitrate that I need. After posting here in StackOverflow: http://stackoverflow.com/questions/34930699/cant-use-youtube-dl-to-download-specified-bitrate/34930832?noredirect=1#comment57644155_34930832, a user there informed me that I'm probably experiencing another instance of a previous bug that skipped post-processing on M4A files.

Here's what I'm getting when I try to extract and transcode:

B:\Users\Hashim>youtube-dl --extract-audio --audio-format m4a --audio-quality 19
2k --playlist-items 48 https://www.youtube.com/playlist?list=PLR
3nWwHlZ9WBpi3uWsjSe6r1PiA8MTbnE
[youtube:playlist] PLR3nWwHlZ9WBpi3uWsjSe6r1PiA8MTbnE: Downloading webpage
[download] Downloading playlist: Main Playlist
[youtube:playlist] PLR3nWwHlZ9WBpi3uWsjSe6r1PiA8MTbnE: Downloading page #1
[youtube:playlist] PLR3nWwHlZ9WBpi3uWsjSe6r1PiA8MTbnE: Downloading page #2
[youtube:playlist] PLR3nWwHlZ9WBpi3uWsjSe6r1PiA8MTbnE: Downloading page #3
[youtube:playlist] PLR3nWwHlZ9WBpi3uWsjSe6r1PiA8MTbnE: Downloading page #4
[youtube:playlist] playlist Main Playlist: Downloading 1 videos
[download] Downloading video 1 of 1
[youtube] -o36bO1XKnw: Downloading webpage
[youtube] -o36bO1XKnw: Downloading video info webpage
[youtube] -o36bO1XKnw: Extracting video information
[youtube] -o36bO1XKnw: Downloading DASH manifest
[download] Destination: B:\Users\Hashim\Desktop\New Folder\Have Mercy - Cigarett
es And Old Perfume.m4a
[download] 100% of 6.24MiB in 00:13
[ffmpeg] Correcting container in "B:\Users\Hashim\Desktop\New Folder\Have Mercy -
Cigarettes And Old Perfume.m4a"
[ffmpeg] Post-process file B:\Users\Hashim\Desktop\New Folder\Have Mercy - Cigar
ettes And Old Perfume.m4a exists, skipping
[download] Finished downloading playlist: Main Playlist

Note the final line, "Post-process file x exists, skipping"

Thanks, would really appreciate a fix for this as soon as possible as it's preventing me from getting my music in the format and quality I need.

[phihag]

I don't think this is a bug - you get the file in the quality that YouTube offers. Recoding to 192k will only ever worsen quality. Can you elaborate why you need 192k bitrate?

[Kaos-Industries]

Previous experience of downloading the entire playlist tells me that the original quality of the audio files I'm extracting are always above 192k. I'm wanting to limit everything at 192k so as to preserve space on the phone that I'll be transferring these files to; I understand that there'll be some loss in quality, but 192k seems to provide the ideal balance between good quality and conservation of space. I may have misunderstood, but isn't the whole point of encoding to convert to other than what the original files on YouTube are?

[dstftw]

Alternatively you can use format selection to select closest to 192k audio format -f "bestvideo+(bestaudio[abr<=192]/bestaudio)/best". This won't involve conversion at all.

[Kaos-Industries]

From what I understand, that would just grab audio less than or equal to 192kbps. As stated above, few files in my YouTube playlist are that low, and I'm wanting to convert the ones that aren't to 192kbps, because as they currently are, they'd take up way too much space on my phone.

[phihag]

@dstftw But that will yield 128k formats. No, wanting to recode seems totally fine under these circumstances.

[Kaos-Industries]

Is this actually a bug, then, or expected behaviour? If the latter, what exactly is the purpose of the encoding/conversion features if this isn't it - how are they typically expected to be used? I was under the impression this would be a typical use case.

[phihag]

@Kaos-Industries This is a bug, and you are using the audio conversion feature as intended.

[Kaos-Industries]

Brilliant, thanks for that. Do you know roughly how long it might take to fix?

[dstftw]

@phihag I'm aware of that, this is just an alternative solution.
@Kaos-Industries note that with your approach for original audios under 192k you'll end up with them upconverted to 192k.

[phihag]

@Kaos-Industries Accurately estimating time to complete a bug is really hard and is likely to increase actual completion time.

[phihag]

I see a number of problems in fixing this:

• The fixup step is not necessary, but taken anyways when we recode.
• It looks like there is a problem with quality recoding with m4a - even when not skipping and fixing, the quality is not changed.
• We need to distinguish already recoded files from just downloaded files in order to avoid recoding twice.

[Kaos-Industries]

@dstftw I get that, but because there's so few of them (maybe 20 in a playlist of 400), it shouldn't be hard to avoid recoding those.

@phihag Fair enough. Thanks for the prompt responses and good luck with getting it ironed out, I look forward to it.

[Kaos-Industries]

Just wondering whether there's been any progress on this front?

[Kaos-Industries]

Could anyone add a postprocessors label to this issue? It seems to be a post-processing issue, so I thought that label would be useful, but I can't seem to be able to do that.

[SimonMcN]

This still seems to be occurring. For me, I find it odd that it disappears if you use don't use the -x flag. If that helps.
Almost like the input and output filename for the ffmpeg process are the same
Simon

[Kaos-Industries]

@SimonMcN You used both "use" and "don't use" in that post. :P Did you mean if you don't
use the -x flag?