.WAV files are deleted after decoding attempt

[hat3k]

Hello. In case you accidentally try to decode .WAV instead of .FLAC there is an error shown:

ERROR while decoding metadata state = FLAC__STREAM_DECODER_END_OF_STREAM Press any key to continue . . . and .WAV file disappears.

build is taken here https://github.com/xiph/flac/actions/runs/11893043149

[ktmf01]

Please provide the command used and the whole output

[hat3k]

C:\test>flac.exe -d -f 1.flac

flac 1.4.3 Copyright (C) 2000-2009 Josh Coalson, 2011-2024 Xiph.Org Foundation flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Type `flac' for details.

1.flac: done

C:\test>flac.exe -d -f 1.wav

flac 1.4.3 Copyright (C) 2000-2009 Josh Coalson, 2011-2024 Xiph.Org Foundation flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. Type `flac' for details.

1.wav: ERROR while decoding metadata state = FLAC__STREAM_DECODER_END_OF_STREAM

C:\test>

[ktmf01]

Thanks. This behaviour is expected although a little 'clumsy'. I'll look into it.

[H2Swine]

I had started looking into flac.md, and maybe I should open an entire new issue on the help file and the handling of input files, but this behaviour is at least at odds with it. This example shows that at least when -d is used, flac assumes a .wav file with RIFF WAVE headers to be FLAC even still - and that is contrary to this text:

flac assumes that files ending in “.wav” or that have the RIFF WAVE header present are WAVE files, files ending in “.w64” or have the Wave64 header present are Wave64 files, files ending in “.rf64” or have the RF64 header present are RF64 files, files ending in “.aif” or “.aiff” or have the AIFF header present are AIFF files, files ending in “.flac” or have the FLAC header present are FLAC files and files ending in “.oga” or “.ogg” or have the Ogg FLAC header present are Ogg FLAC files.

So I tested the following: copied a flacfile.flac to flacfile.wrongextension.aiff, flacfile.wrongextension.w64, flacfile.wrongextension.rf64, flacfile.wrongextension.ogg and flacfile.wrongextension.oga. Then tried to flac -d each of them. The three former produced .wav output. The two latter did not. On the other hand, "re-encoding" works for all. (Putting "re-encoding" in quotation marks, because nothing is overwritten when the original extension wasn't ".flac" - even if it is ".fla", it doesn't replace files.) (edit: undid nonsense edit)

Which brings me to asking what the encoder/decoder actually does under all circumstances (hm, does foreign metadata change anything?) - and maybe ask whether something is pending a change, rather than writing an elaborate help file text that is about to become obsolete.

(Honestly it looks puzzling that if it knows headers, it relies on filenames; if it knows headers, it doesn't need filename - and if it doesn't know the headers of the file, it cannot use the filename for anything?)

[H2Swine]

Maybe this should have been a separate issue ( @ktmf01 ?), but:

I did further testing on this, confirming it:

tested the following: copied a flacfile.flac to flacfile.wrongextension.aiff, flacfile.wrongextension.w64, flacfile.wrongextension.rf64, flacfile.wrongextension.ogg and flacfile.wrongextension.oga. Then tried to flac -d each of them. The three former produced .wav output. The two latter did not. On the other hand, "re-encoding" works for all

So, when encoding from a FLAC file with no extension or wrong extension, works - but decoding (and testing) fails if the wrong extension is .oga/.ogg , then it cannot recognize it.

Worse is when trying decoding OGG FLAC files with wrong (or no) file extension. Then everything goes wrong.

Also, flac infile -o outfile.oga produces FLAC files not OGG FLAC.

"My" concern about this is that I was trying to make sense of the flac.md help file, which is in part wrong. But if there is a chance that this will be fixed, making reality catch up with the help file ... ?

[ktmf01]

Maybe this should have been a separate issue ( @ktmf01 ?), but:

Yes, I've opened a new issue.

[hat3k]

Not going to bother, but deleting the wav file could be quite a sad event and probably shouldn't be in the release version.

[ktmf01]

Similarly using rm -rf / is also a sad event. Use of -f or --force can result in all kinds of sad events. In this particular case, it is a little clumsy that flac doesn't notice the impossibility of the request. However, I've checked, and there is no easy fix.

If someone has a patch, I'd be more than happy to take a look at it. But I won't consider this blocking.

[hat3k]

Ok. I hope in the future there will a possibility of not removing input file in case of an error.

[ktmf01]

That possibility is already there: just don't use -f nor --force

[hat3k]

That could be a solution, but -f is "Force overwriting of output files", not input ones.

[ktmf01]

Yes, but in this case the input file and the output file are the same, because the command doesn't make sense.