Problems importing R24 .WAV data

Installation & Configuration Linux
#1

Ardour 5.12.0 on Fedora27.

I tried to import data from an existing Zoom R24 project, to find that Ardour refuses to import the WAV data files. According to the import dialog, the files are “not usable”.

Ardour seems to use libsndfile, so I tried sndfile-info:

    Error : Not able to open input file STE-000.WAV.
    File : STE-000.WAV
    Length : 40424480
    RIFF : 40424472
    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 (262D420) at position 393212. Exiting parser.

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

However, most other tools (mplayer, audacity) do not have any problems with these WAV files.

#2

My Zoom R24 is in the mail, i just ordered it :slight_smile:

Could you try what mediainfo tells about the files: mediainfo InputFile

Will sox create a correctly formed file ? You can try it with this command: sox InputFile.wav OutputFile.wav

If not you could try to fix the file with ffmpeg like this: ffmpeg -i InputFile.wav -acodec pcm_s24le OutputFile.wav

#3

mediainfo:

General
Complete name                            : STE-000.WAV
Format                                   : Wave
File size                                : 29.8 MiB
Overall bit rate mode                    : Constant

Audio
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : 1
Bit rate mode                            : Constant
Bit rate                                 : 1 411.2 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Bit depth                                : 16 bits

And yes, sox produces WAV files that Ardour can import without a whimp. I assume ffmpeg will also.
However, it would be a nuisance if I need converting all of the time…

#4

As Ardour uses sndfile for im- and export I would suggest to run sndfile-info InputFile.wav to see what it reports…

#5

@Arnd you probably did not notice but the op already scanned the file with sndfile-info and sndfile thinks the header information of the file is broken.

I will look into this when my R24 arrives. If we need a small commanline utility that corrects the header information of the project wav - files then I will probably write one. In the meantime a folder of files can be fixed and written to another folder like this:

cd SourceDirectory
find . -name “*.wav” -exec sox {} TargetDirectory/{} ;

#6

Well, there may be workarounds but eventually one or more out of Zoom R24, libsndfile and Ardour will have to fix something.

My Zoom H2n produces WAV files that are acceptible to libsndfile.

I’m currently trying to find out how the WAVs from a Zoom L12 are.

#7

The R24 files might be “broken” somehow and different libraries might handle these differently. The fact that mediainfo did not print any info for the R24 file duration seems to hint to that direction. Here is info that it print for a correct wav file:

mediainfo testi.wav General Complete name : testi.wav Format : Wave File size : 2.75 MiB Duration : 30 s 0 ms Overall bit rate mode : Constant Overall bit rate : 768 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 30 s 0 ms
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 1 channel
Sampling rate : 48.0 kHz
Bit depth : 16 bits
Stream size : 2.75 MiB (100%)
#8

See https://github.com/erikd/libsndfile/issues/370 .

#9

Thanks for reporting this to libsndfile. As I don’t yet have my device I can not test it but reading the manual there seems to be two ways of getting wavs out of the R24. One way is just to disconnect the SD - card that the device records to and put in a card reader. The other is to plug a USB - stick into the R24 and telling the device to copy a project over to it. I wonder if the latter method also fixes the wav headers ?

#10

I verified that copying an audio file to USB stick produces an identical file as can be copied using card reader mode. I would really be surprised if not…

Since it turns out to be a small software error in libsndfile, we do no longer need to worry about the correctness of the R24 files. As far as it matters they are correct.

Erik has accepted my fix for libsndfile and it will be part of the next release. I have rebuild my library with the fix and ardour now imports the Zoom WAVs without problems.

#11

Still I would like to see some R8 / R16 WAVs for comparison…

#12

A future Zoom R24 user thanks you :slight_smile:

#13

This is known regression in libsndfile-1.0.28 and the reason why Ardour binaries from ardour.org still come with libsndfile-1.0.27.

#14

FYI: The Fedora ardour5 package provides a dynamically linked binary, so it will use whatever libsndfile is installed. Currently (Fedora 27 and 28) that is 1.0.28.

#15

Yes, we know. That’s x42’s whole point. We do our own packaging to avoid issues like this.

#16

Which is highly appreciated!

#17

I have an almost identical problem with files from a Zoom R16. These same files worked a week ago in Ardour 4, but I updated Ubuntu Studio to 18.04 and it automatically updated Ardour to Ardour 5. Now Ardour 5 says the files are “not usable.”

Here is what sndfile-info says:

Error : Not able to open input file /media/vms/TI106169W0D/Users/VMS/Project folders/Karon/Genesis Audio/Music Raw Recordings/PROJ002/AUDIO/MONO-000.WAV.
File : /media/vms/TI106169W0D/Users/VMS/Project folders/Karon/Genesis Audio/Music Raw Recordings/PROJ002/AUDIO/MONO-000.WAV
Length : 35192832
RIFF : 35192824
WAVE
fmt : 16
Format : 0x1 => WAVE_FORMAT_PCM
Channels : 1
Sample Rate : 44100
Block Align : 2
Bit Width : 16
Bytes/sec : 88200
LIST : 196556
*** Found weird-ass zero marker. Jumping to end of chunk.
Request for header allocation of 393112 denined.
*** Offset is now : 0x2FFFC
*** Unknown chunk marker (2160000) at position 196604. Exiting parser.
*** Chunk size 4294836224 > file length 35192832. Exiting parser.

Error in WAV file. No ‘data’ chunk marker.

So is this something that got changed in Ardour5, or something that got changed in Ubuntu Studio? If I just need to update my libsndfile, how would I go about doing that?

#18

This is a known and long standing problem with libsndfile. Unfortunately, AFAIK the maintainers of libsndfile have (want?) not fix it.
For reasons like this, it is better to download the binary from the Ardour site, it is statically linked with working libraries.

And complain LOUDLY to Ubunto that they are shipping a defective libsndfile library.

If you want to fix/build your own libsndfile library I can provide a patch against 1.0.28.

#19

I’ve never tried fixing my libsndfile library, but I’m willing to give it a try. I may have to do this every time I update Ubuntu Studio until Ubuntu stops shipping 1.0.28

#20

I have the same problem (Fedora) and the trick that I use is to give the self-built package a higher version number so it will not automatically be updated.

Anyway, the fix is in line 967 of src/wavlike.c: just remove “+ 4” from the argument of psf_binheader_readf. The line becomes:

bytesread += psf_binheader_readf (psf, "j", chunk_length - bytesread) ;

HTH

1 Like