slhck
APIC Tags not copied to output file.
If you want to report a bug, or have a specific question, please make sure to include this information:
- [ Ubuntu 18.04 LTS] Your operating system
- [Python 3.6.5] Your Python version / distribution
- [ 3.4.2-2] Your ffmpeg version
- [ffmpeg-normalize --debug -o "Music/temp-music/01 - What Story Down There Awaits Its End_.mp3" -f -c:a libmp3lame --extra-output-options '["-b:a", "128k", "-ar", "44100", "-write_id3v2", "3", "-write_xing", "0"]' "Music/temp-music/01 - What Story Down There Awaits Its End_.mp3" ] The exact command you were trying to run
- [ffmpeg-normalize-debug.txt
] Any output you get when running the command with the
--debugflag
Running second pass (debug text line 125) - ffmpeg-normalize appends bogus text ([norm0]) to end of -filter_complex option and sets bogus value ([norm0]) for -map option. Constructed command not enough to cause ffmpeg to fail, but enough to ignore APIC tags (at least).
Not sure what the specific question is. Can you elaborate on the "APIC tags"?
The norm0 is not bogus—it's the output of the normalization filter.
More a bug report than a question.
APICS tag is album cover art stored as a binary stream. I found nothing in the FFMPEG documentation that supports your claim that -- print_format=json[norm0] and -map [norm0] -- are not bogus. Please study the syntax of line 125 of my original debug attachment more carefully. You'll see that both instances of bracketed norm0 are misplaced and impinge upon the functionality (in some way) of at least the -map_metadata option.
When I adapt the programmatically constructed FFMPEG command captured on line 125 of my debug attachment for command-line execution independent of your wrapper code, the APIC tag is successfully copied only when -- print_format=json and -map 0 -- is passed in compliance with FFMPEG documentation.
Would you please point me to written ffmpeg documentation addressing norm0? I couldn't find anything. If it's a value internal to your wrapper code rather than meaningful to ffmpeg itself, then this issue is most likely a bug.
Sent from TypeApphttp://www.typeapp.com/r?b=12967 On May 14, 2018, at 9:11 PM, Werner Robitza <[email protected]mailto:[email protected]> wrote:
Not sure what the specific question is. Can you elaborate on the "APIC tags"?
The norm0 is not bogus—it's the output of the normalization filter.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/slhck/ffmpeg-normalize/issues/72#issuecomment-389010578, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AElNOCDu7Atg9X8p6vR-6-Y-QYg91Tncks5tyisvgaJpZM4T-Z_6.
I found nothing in the FFMPEG documentation that supports your claim that -- print_format=json[norm0] and -map [norm0] -- are not bogus.
norm0 is a custom filter output label which is later mapped to the output file. It could also be called foo0 or anything else.
The reason for the image not being mapped to the output is that it is considered a video (as you can see from the debug log): Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 700x700 [SAR 72:72 DAR 1:1], 90k tbr, 90k tbn, 90k tbc — if I'm not mistaken, the program assumes that MP3s cannot carry video data and therefore does not copy the extra info.
When you say you adapted the command successfully, what exactly was that command? The -map 0 will probably work in your case but it's not generalizable.
norm0 may very well be a custom filter output label meant to serve some intended purpose, but, as you can see in bold below, it is twice misused in your generated command (1).
Attached is a easytag screenshot showing the so-called "video" is, in fact, a jpeg.
The first command will produce a /tmp/ry7z4g7u.mp3 without the embedded jpeg (APIC tag). The second command will.
- Adapted Second Pass command (as is) to run via terminal:
/usr/bin/ffmpeg -y -nostdin -i "Music/temp-music/01 - What Story Down There Awaits Its End_.mp3" -filter_complex '[0:0]loudnorm=i=-23.0:lra=7.0:tp=-2.0:offset=0.0:measured_i=-24.23:measured_lra=5.2:measured_tp=-10.67:measured_thresh=-34.4:linear=true:print_format=json[norm0]' -map_metadata 0 -map_chapters 0 -c:v copy -map [norm0] -c:a libmp3lame -c:s copy -b:a 128k -ar 44100 -write_id3v2 3 -write_xing 0 /tmp/ry7z4g7u.mp3
2)Adapted Second Pass command with modifications:
/usr/bin/ffmpeg -y -nostdin -i "Music/temp-music/01 - What Story Down There Awaits Its End_.mp3" -filter_complex '[0:0]loudnorm=i=-23.0:lra=7.0:tp=-2.0:offset=0.0:measured_i=-24.23:measured_lra=5.2:measured_tp=-10.67:measured_thresh=-34.4:linear=true:print_format=json' -map_metadata 0 -map_chapters 0 -c:v copy -map 0 -c:a libmp3lame -c:s copy -b:a 128k -ar 44100 -write_id3v2 3 -write_xing 0 /tmp/ry7z4g7u.mp3
I found the ffmpeg filters documentation and even though it's going to take more time to make sense of linklabels, by all indications, your generated command syntax is, in fact, correct. Please accept my apologies.
Nevertheless, the issue remains unresolved. When your generated ffmpeg command with linklabels is executed independently (command 1 from my last comment), the binary jpeg stream (as reported by ffmpeg as the video stream #0:1) is not copied to the output file. On the other hand, when your command is doctored (command 2 from my last comment), the "video stream" is copied to output as desired. Therefore, the issue is inexplicably tied to the linklabels.
The issue is that the video stream is not mapped explicitly, as the output is an audio file and it'd cause most conversions to fail if the input had a real video inside, and not just album art. I'll look into it once I find more time (currently traveling).
I'm going to close a few issues that I've had no time to work on. PRs are welcome.