[Ardour-Users] Painful importing WAV files withconstant crashing/segfaulting

[Ken Restivo]

On Fri, Feb 26, 2010 at 09:45:41AM -0500, plutek-infinity wrote:
> >From: Arnold Krille <arnold at arnoldarts.de>
> >Date: Fri, 26 Feb 2010 10:08:56 +0100
> 
> >And there might be public interest in such a script:-)
> 
> if i qualify as "public", then the above is definitely true!
> 
> cheers! (in more ways than one)

OK, well I'm nearly done with the script. It is *very* hackish and probably won't be too useful for too many people, but I might could update it later.

Here's Stupid Question #2:

I'm comparing what my script is doing, compared to what Ardour's native importer is doing, and there's a discrepancy I can't figure out.

Ardour shows the test file/region I'm importing as having 131595 frames. But but...

$ sndfile-info originalfile.wav |grep Frames
Frames      : 143232

Huh? Where's it getting that other number. Let's see...

$ sndfile-info test/interchange/test/audiofiles/* |grep Frames
Frames      : 131595

OK, so it's reading the converted file's frame count correctly. But what is it about Ardour's conversion that is somehow eating 11637 frames?

The format conversion, maybe? Can't seem to duplicate that:

$ sndfile-convert -float32 originalfile.wav 32bitfile.wav
$ sndfile-info 32bitfile.wav |grep Frames
Frames      : 143232

WTF??

Looking at the Ardour code, or what I think is the code (import.cc), all it seems to be doing in this case (the source file is a 32-bit float test file anyway) is deinterleaving. If I do my deinterleaving with ecasound, I still end up with  143232 frames though.

$ ecasound -a:1,2 -i originalfile.wav -a:1 -f:32,1,44100 -o mono_L.wav -a:2 -f:32,1,44100 -o mono_R.wav -chcopy:2,1

$ sndfile-info mono*.wav |grep Frames
Frames      : 143232
Frames      : 143232

Very odd. Ardour makes 11637 frames disappear, and I can't figure out why.

-ken