Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC - stored main chunk length differs from written length (Read 3394 times) previous topic - next topic - Topic derived from FLAC-git Releases (Co...
0 Members and 1 Guest are viewing this topic.

Re: FLAC - stored main chunk length differs from written length

Reply #50
On to the wrong.wav, after having looked at it ... I don't know that WAVE specification, but https://learn.microsoft.com/en-us/windows/win32/api/mmeapi/ns-mmeapi-waveformat doesn't say anything about what information takes precedent in case of inconsistencies. Here we have nChannels=1, nBlockAlign=4 and wBitsPerSample=16, and so if we for the sake of discussion assume that no more than one of these is wrong: Is there anything that says that this file should be interpreted as
* mono with 4 bytes per channel, i.e. wBitsPerSample is wrong and should be replaced by 32?
* 4 bytes per channel and 16 bits, i.e. nChannels is wrong and should be replaced by 2?
* mono with 16 wBitsPerSample, i.e. nBlockAlign is wrong and should be replaced by 2?
There is a consistent interpretation (i.e., assuming no values are "wrong"), which is mono 16-bit samples in 32-bit containers. That's obviously kind of weird, but 24-bit samples in 32-bit containers is a thing, and this is how WavPack interprets it because I initially thought it would be a good idea to handle those cases. Unfortunately, since there are no files like this and the spec kinda says that it's not a thing (or how the sample would be justified, if it was a thing), this "feature" doesn't get exercised and doesn't work now (if it ever did).

Quote
  
As far as I can tell,
flac, TAK and OptimFROG reject it
Monkey's roundtrip it to bit-exactly the original
WavPack is fooled by it, into unpacking it to something else
ffmpeg thinks it is ten seconds long, I assume then it disregards nBlockAlign although I didn't bother to listen
foobar2000 seems to do the same thing when playing it.
I will start rejecting these as well, rather than trying to make my interpretation above work correctly.

Another reminder to always use the -v (verify) option when encoding with WavPack (it catches this one of course).   ;D


Re: FLAC - stored main chunk length differs from written length

Reply #51
There is a consistent interpretation (i.e., assuming no values are "wrong"), which is mono 16-bit samples in 32-bit containers.
Oh. Yes this is old WAVE. And, *sighs*, my memory isn't the best ... This thread: https://hydrogenaud.io/index.php/topic,121447.msg1008257.html#msg1008257
Anyway, a stereo 16 in 32 from that collection attached, and it completely beats me why that works with FLAC/WavPack/OptimFROG and the mono doesn't ... rookie mistakes, moi?

Re: FLAC - stored main chunk length differs from written length

Reply #52
Fixing broken WAV files with SoX
https://langdoc.github.io/2017-05-28-sox-trick.html

Code: [Select]
PS E:\download> .\sox junglede.wav junglede.flac
E:\download\sox.exe WARN wav: Premature EOF on .wav input file
PS E:\download> .\sox --ignore-length junglede.wav ignore.flac
PS E:\download> dir *.flac|select length,name

Length Name
------ ----
 44203 ignore.flac
371537 junglede.flac

The fun thing is, without using --ignore-length, the encoded flac file is even larger than the input .wav file, in both Rarewares and NetRanger's versions.

 

Re: FLAC - stored main chunk length differs from written length

Reply #53
On to the wrong.wav
...
As far as I can tell,
flac, TAK and OptimFROG reject it
...
Add refalac to the list, and thanks Bryant for the attention.

Re: FLAC - stored main chunk length differs from written length

Reply #54
Add refalac to the list, and thanks Bryant for the attention.
Although qaac/refalac's own WAV parser rejects wrong.wav, refalac will try with libsndfile when it is available, and libsndfile happily load it.
In case of qaac, it will be loaded by CoreAudio's ExtAudioFile API even when libsndfile is not available.

Re: FLAC - stored main chunk length differs from written length

Reply #55
Thanks for the tips. I extracted refalac.exe from foobar's free encoder package without using other libraries, so didn't know about these details.

Re: FLAC - stored main chunk length differs from written length

Reply #56
Well, it's just a shortcoming of how qaac/refalac handles input files. It just tries each handler one by one until it succeeds.
Usually it works, but occasionally behavior becomes less predictable to the user.

Re: FLAC - stored main chunk length differs from written length

Reply #57
On to the wrong.wav
...
As far as I can tell,
flac, TAK and OptimFROG reject it
...
Add refalac to the list, and thanks Bryant for the attention.
I have fixed this in WavPack with this commit by rejecting such WAV files.

While I was fixing this I looked at other formats and see that CAF also has this redundancy and, unlike WAV, the format documentation clearly states that having unpacked samples is valid and gives a detailed example of the 24-bit sample in 32-bit container case (values are shifted "up" for both BE and LE).

I created a few sample files like this and found that WavPack handled them fine, except for not verifying that the proper bytes were zeroed. I tried other programs and FFmpeg and Audacity (via libsndfile) both fail on these files. The only other program that handled them correctly was (no surprise) @nu774 's Foobar2000 CAF component. Good job!

If anyone is interested, I can attach them to the thread.
 

Re: FLAC - stored main chunk length differs from written length

Reply #58
I have fixed this in WavPack with this commit by rejecting such WAV files.
Thanks. Cool Edit / Audition 24.0 float files use 4 bytes block align and 24 bits per sample in header, will these files be affected? Here are some sample files saved with Audition 1.5:
https://hydrogenaud.io/index.php?action=dlattach;topic=114816.0;attach=22034
[edit]Warning to innocent lurkers: Some of these files are not safe to play outside of Cool Edit / Audition, beware of loud noise!

Re: FLAC - stored main chunk length differs from written length

Reply #59
I have fixed this in WavPack with this commit by rejecting such WAV files.
Thanks. Cool Edit / Audition 24.0 float files use 4 bytes block align and 24 bits per sample in header, will these files be affected? Here are some sample files saved with Audition 1.5:
https://hydrogenaud.io/index.php?action=dlattach;topic=114816.0;attach=22034
[edit]Warning to innocent lurkers: Some of these files are not safe to play outside of Cool Edit / Audition, beware of loud noise!
Yes, thanks for reminding me of these! The 24.0 float files are indeed broken now. Will need to come up with a more complete fix.

Re: FLAC - stored main chunk length differs from written length

Reply #60
Perhaps only accept type 1, 24 bits per sample, 4 bytes block align per channel files when -a is being used. Otherwise signal analysis on the data chuck would be required to guess the audio encoding format, for example, if it is really unpacked 24-bit int.

This should be relevant:
https://hydrogenaud.io/index.php/topic,121447.msg1009022.html#msg1009022