[linux-audio-user] Wave file conversion (multi-mono->stereo, then downsample/downsize, then dither)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 09, 2004 at 02:33:57PM -0700, Mark Knecht wrote:
> On Thu, 2004-09-09 at 14:07, Eric Dantan Rzewnicki wrote:
> > Here is one way to be sure ecasound uses libsamplerate:
> > ecasound -f:16,2,44100 -i:resample-hq,auto,hi-quality.wav -o:lower-quality.wav
> > The resample-hq input object type, with the auto flag, is a special type
> > that causes ecasound to automatically read the format of the input .wav
> > and resample it using libsamplerate to match the format set for the rest
> > of the chain. I imagine the above command will fail if ecasound is not 
> > compiled with src support. There is a similar resample object that uses
> > the internal linear interpolation. For both object types auto can be
> > replaced with the actual sample format if your input file format lacks 
> > that info. One example would be raw input files.
> It ran, but it did not apparently downsample. Granted I took a mono file
> as input and wrote a stereo file out, but the output sample rate is
> still reported as 96K. I will try your 2-mono to stereo example in a
> minute.
> 
>  ecasound -f:16,2,44100 -i:resample-hq,auto,
> data/GTSB-96K-24bit-Audio/T01-Startdust.L.wav -o:TEST1.wav

I think you just have an extra line break or space in your commandline.

-Eric Rz.


> ****************************************************************************
> *               ecasound v2.3.3 (C) 1997-2004 Kai
> Vehmanen                 
> ****************************************************************************
> - [ Session created ]
> ------------------------------------------------------
> - [ Chainsetup created (cmdline) ]
> -----------------------------------------
> (eca-chainsetup-parser) Note! Interpreting option
                          ^^^^^^^^^^^^^^^^^^^^^^^^^
> data/GTSB-96K-24bit-Audio/T01-Startdust.L.wav as
> -i:data/GTSB-96K-24bit-Audio/T01-Startdust.L.wav.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This doesn't look correct. The parser saw the "data/.../...wav" 
separately from the "-i:resample-hq,auto,". Did you perhaps have a space
in there by accident? (or maybe in my example?)
This message typically comes out if you don't specify a -i: option at
all. The commandline parser defaults to interpreting the first thing
that looks like a filename as the input.


> - [ Connecting chainsetup ]
> ------------------------------------------------
> (eca-chainsetup) 'nonrt' buffering mode selected.
> Warning: DBC_CHECK failed - "samples_per_second() > 0", audioio.cpp,
> 195.
> Warning: DBC_CHECK failed - "samples_per_second() > 0", audioio.cpp,
> 195.
  ^^^^^^^
These point to it trying to autodetect the sample rate and not finding
anything valid, I think.

> (eca-chainsetup) Audio object "", mode "read".
                                ^^^
This looks like it interpreted your -i:resample-hq,auto, as having an 
empty string for the filename ...
> (audio-io) Format: s16_le, channels 2, srate 44100, interleaved.
and since it couldn't find a samplerate in the non-existent file it went
with the sample rate you set with the -f:16,2,44100 at the start of your
commandline. Which doesn't matter, because this file doesn't exist
anyway.

> (eca-chainsetup) Audio object
> "data/GTSB-96K-24bit-Audio/T01-Startdust.L.wav", mode "read".
> (audio-io) Format: s24_le, channels 1, srate 96000, interleaved.
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
and then here it saw the filename by itself as a second input and read
the format from the wav headers. Since the resample-hq type didn't stick
to this file, the sample rate for the rest of the chain is overridden by 
that in the wav file ...
> (eca-chainsetup) Audio object "TEST1.wav", mode "read/write".
> (audio-io) Format: s16_le, channels 2, srate 96000, interleaved.
> - [ Chainsetup connected ]
leading to your output file inheritting that sample rate, and your 
operation basically doing nothing for you other than down sample to 16
bits.


Strictly speaking, I don't think the resample-hq or resample object type
is necessary to get _some_ sort of resampling. It's an explicit way to
ensure the type of resampling you want is used. Or something along those
lines. Hopefully Kai will correct me if I'm mixed up, but I think I'm at
least very close.

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux