avoid doubling file extensions in example for recursively batch processing with `find`?

[EG-tech]

In the "Batch Processing (Mac/Linux)" section, there's an example variation provided for recursively processing files contained in sub-directories using find, rather than the standard for loop for processing within the same directory - this was super helpful to me for a completely different/non-AV batch processing task, but as @kieranjol noted when originally suggesting the current one-liner, the limitation with sending find output directly into the ffmpeg command with -exec is that you wind up doubling up on file extensions in the output file name, e.g. filename.mxf.mov

I'm a bit torn here - on the one hand, the current version is definitely simpler/quicker to understand, on the other hand, it's a bit confusing if you're not expecting that output, and trying to batch rename from Bash after-the-fact is a can of regex worms.

It would require a bit more text to explain the loop, but what about:
find input_directory -iname "*.mxf" -print0 | while read -d $'\0' file; do ffmpeg -i "$file" -map 0 -c copy "${file%.mxf}.mov"; done?

(see e.g. https://askubuntu.com/a/648990)

[privatezero]

Thanks for opening this @EG-tech! The current formula you linked is set up to work as a .sh file, and I do think we could benefit by having a command in there for one off use in the terminal like yours.

Maybe just a matter of taste, but I tend to form the while loop like this rather than with piping: while read i ; do ffmpeg -nostdin -i "$i" -c copy "$i".mov ; done < <(find input_directory -iname "*.mxf") I have absolutely no idea if that would be technically functioning slightly differently though!

Definitely worth explaining in more detail the issue with the double file extension output and the workaround like you have suggested.

These days I tend to just be lazy and leave the double extension and then clean it up with a batch find/rename in the file browser, but having a 100% bash approach seems very in scope for ffmprovisr!

[EG-tech]

hey @privatezero! sorry if unclear: I don't mean to change up any of the Rewrap-MXF.sh part of that entry, that's all dandy and I believe the piece recommending the ffmpeg output be set to "${file%.mxf}.mov" already resolves any concern with double extensions there.

I'm talking just about the very end of that section, which already has a recommended variation for one-off use with find as opposed to a script:

Variation: recursively process all MXF files in subdirectories using find instead of for:

find input_directory -iname "*.mxf" -exec ffmpeg -i {} -map 0 -c copy {}.mov \;

Running ☝️ that example find command there is the one that would get you double file extensions, and AFAIK there's no way to fix that without sticking the find output into a while loop one way or another. I think you're totally right that both our methods basically do the same thing and are just Bash taste, I ran a test or two and it looks like:

• while read i; do ffmpeg -nostdin -i "$i" -map 0 -c copy "${i%.mxf}.mov"; done < <(find input_directory -iname "*.mxf")
• find input_directory -iname "*.mxf" -print0 | while read -d $'\0' i; do ffmpeg -nostdin -i "$i" -map 0 -c copy "${i%.mxf}.mov"; done

are functionally equivalent (the former is your same method but avoids double file extensions and having to do a batch rename cleanup, FWIW 😉 )

As far as ffmprovisr and explanatory text goes, your method looks simpler since you'd only need to explain < < rather than have to explain print0, read -d $'\0' and the piping! So that seems like a good option, but I admit I actually have to look up what that's doing before I could explain/suggest an explanation myself 😆