New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem importing WAV files #370

Closed
sciurius opened this Issue Mar 13, 2018 · 11 comments

Comments

Projects
None yet
3 participants
@sciurius
Contributor

sciurius commented Mar 13, 2018

All WAV files produced by my Zoom R24 are rejected by libsnd (and libsnd using tools like Ardour).

Given how many years the Zoom R-series have been on the market, if the files were really invalid there would have been a lot of complaints.

The attached WAV file (truncated to make it smaller, unrelated to the error) gives the following sndfile-info output:
`Length : 400000
RIFF : 31239256 (should be 399992)
WAVE
fmt : 16
Format : 0x1 => WAVE_FORMAT_PCM
Channels : 2
Sample Rate : 44100
Block Align : 4
Bit Width : 16
Bytes/sec : 176400
LIST : 393164
*** Found weird-ass zero marker. Jumping to end of chunk.
Request for header allocation of 786328 denined.
*** Offset is now : 0x5FFFC
*** Unknown chunk marker (1D6AC60) at position 393212. Exiting parser.

Error in WAV file. No 'data' chunk marker.`

Inspection with a hex tool shows that the LIST chunk is correctly sized, and that the data chunk therefore starts at 0x5FFF8. In the non-truncated file, the data chunk is also correctly sized.

x1.wav.gz

Full file

@erikd

This comment has been minimized.

Owner

erikd commented Mar 13, 2018

This is "libnsdfile", "libsnd" is another library.

As for the error you're seeing, this is due to your device producing invalid files, or at the very least, files that interpret the very loose (and poor quality) WAV file specs differently to libsndfile and most other software.
The extremely large LIST chunk may be causing the parser to hit a corner case that then cause the parse to fail.

If you or someone else can come up with a clean patch to handle this (almost certainly broken) file (preferably with a test) I'll happy apply it.

@sciurius

This comment has been minimized.

Contributor

sciurius commented Mar 14, 2018

Thanks for your reply.
The LIST chunk may be weird, and large, but the SubchunkSize is correct so there should be no problems to skip over it.
Does libsndfile try to interpret the contents of the LIST? It is all zeroes, is that allowed?

@sciurius

This comment has been minimized.

Contributor

sciurius commented Mar 14, 2018

It seems that the chunk is not correctly skipped when a zero marker is encountered.
The following trivial patch fixes the problem for the Zoom files.
All existing tests (still) pass.

wavskip.patch.txt

erikd added a commit that referenced this issue Mar 14, 2018

@erikd erikd closed this in #371 Mar 14, 2018

erikd added a commit that referenced this issue Mar 14, 2018

@x42

This comment has been minimized.

x42 commented Mar 15, 2018

Similar crash, even with this fix (1.0.26-288-g65eabcbf) using a file from a Zoom handheld device:

File : /home/rgareus/Downloads/MONO-002.WAV
Length : 27293176
RIFF : 27293168
WAVE
fmt  : 16
  Format        : 0x1 => WAVE_FORMAT_PCM
  Channels      : 1
  Sample Rate   : 44100
  Block Align   : 2
  Bit Width     : 16
  Bytes/sec     : 88200
LIST : 393164
    *** ��N
            : 50466568
Request for header allocation of 786320 denied.
*** Unknown chunk marker (19A75F8) at position 393212. Exiting parser.
*** Chunk size 4292673536 > file length 27293176. Exiting parser.

Error in WAV file. No 'data' chunk marker.

It works fine with libsndfile-1.0.27:

File : /home/rgareus/Downloads/MONO-002.WAV
Length : 27293176
RIFF : 27293168
WAVE
fmt  : 16
  Format        : 0x1 => WAVE_FORMAT_PCM
  Channels      : 1
  Sample Rate   : 44100
  Block Align   : 2
  Bit Width     : 16
  Bytes/sec     : 88200
LIST : 393164 (too long)
data : 26899960
End

----------------------------------------
Sample Rate : 44100
Frames      : 13449980
Channels    : 1
Format      : 0x00010002
Sections    : 1
Seekable    : TRUE
Duration    : 00:05:04.988
Signal Max  : 23260 (-2.98 dB)

@erikd I have reported this to you by email on 06/15/2017 01:16 AM +0200 -- I cannot publicly share the file which causes the issue (it's from a Mixbus customer),

@erikd

This comment has been minimized.

Owner

erikd commented Mar 15, 2018

@x42 I can't seem to find any such email. Is it not possible to anonymize this file by overwriting the audio data with zero bytes? Its just PCM data, so no real codec involved.

@x42

This comment has been minimized.

x42 commented Mar 15, 2018

I'll see if I can do that. meanwhile I've re-sent the email

@x42

This comment has been minimized.

x42 commented Mar 15, 2018

Github does not allow attaching the file, so here it is: audio-data starts at 0x00060000, I've zeroed it starting 0x00060010: http://robin.linuxaudio.org/tmp/zoom_sndfile_bug.wav.gz

Once unzipped, it plays fine with mplayer, ffmpeg.. and tools using libsndfile 1.0.27, but not libsndfile 1.0.28 or later.

the *** ��N comes from the "%M" in src/wavlike.c:1035

@x42

This comment has been minimized.

x42 commented Mar 15, 2018

PS. should I open a new bug-report, or is this the same underlying issue?

@erikd

This comment has been minimized.

Owner

erikd commented Mar 15, 2018

Yes, please open another issue.

@sciurius

This comment has been minimized.

Contributor

sciurius commented Mar 16, 2018

Peculiar... The size of the LIST is exactly the same as the LIST subchunk of the Zoom R24 WAVs.
@x42 What handheld device did you use?

@x42

This comment has been minimized.

x42 commented Mar 16, 2018

The list-chunksize being identical and the request for header allocation .. denied is why I thought the issues are related if not the same.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment