`flac` is inconsistent in when it uses an extension or file magic
See https://github.com/xiph/flac/issues/763#issuecomment-2553597252_
I am by no means competent to do anything about the way the command-line tool handles file, but when you have had time to think over what should be done:
Is there any use in updating the flac.md help file to reflect what current git version does?
Oh, it is maybe not that hard to write - worse is that it might be cumbersome to read and digest. But I think this reflects current reality?
flac will detect input file format from file headers upon encoding and re-encoding, outputting a FLAC file except overridden by
--ogg. Upon decoding, it will assume that input is a FLAC file (--oggis necessary upon decoding an Ogg FLAC file), and can set output file type either (1) by specifying output name ending in ".wav", ".rf64", ".w64", ".aif" or ".aiff", or (2) by format options, which also can set a particular version of RIFF WAVE or AIFF, or (3) possibly inferred if the FLAC file has stored the non-audio chunks of the original source - such are not stored by default. In the absence of (1) to (3), output will default to RIFF WAVE. flac makes no further assumptions about file extensions, though the convention is that FLAC files end with ".flac" (or ".fla" on ancient "8.3" file systems like FAT-16), and that Ogg FLAC files end with .oga.
Then the second command-line under SYNOPSIS should maybe be as long as this?
flac [ -d | --decode | -t | --test | -a | --analyze ] [ OPTIONS ] [ infile.flac | --ogg infile.oga | --ogg infile.ogg | - ... ]
<edit> removed -v and -h, they don't belong there. But maybe
--ogg infile[.ogg|.oga]
pointing out that extension is optional. (I did not capitalize filename here. man pages like e.g. gzip and xz don't.) </edit>
If you think they are worth it, I could try to work one or both into flac.md for a PR.
Hm, what options does -t even take? -w, -s and if applicable --ogg - and then it does ignore a few?