18 Apr
2020
18 Apr
'20
12:51 p.m.
I use a program which plays regions of various .wav files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
Thank you.
--
John.
18 Apr
18 Apr
12:55 p.m.
On Sat, 18 Apr 2020 09:50:30 +0100
John Murphy <rosegardener(a)freeode.co.uk> wrote:
I use a program which plays regions of various .wav
files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
Thank you.
Use arecord instead.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
2:06 p.m.
On Sat, 18 Apr 2020 09:55:12 +0100 Will Godfrey wrote:
On Sat, 18 Apr 2020 09:50:30 +0100
John Murphy <rosegardener(a)freeode.co.uk> wrote:
Thanks. I saw the -C switch (or arecord), but didn't try it because
the examples I've seen had hardware input.
It doesn't work though. A file gets created with a reasonable looking
header, but all zeros where the data should be and it never stops,
so I have to CTRL C.
If I simply '>' the input, which was going to aplay, to a file, it's
done in a flash. Unplayable, but the file contains data. Could I write
a header first somehow? Or a container format would be OK.
--
John.
I use a program which plays regions of various
.wav files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
Thank you.
Use arecord instead.
19 Apr
19 Apr
2:39 a.m.
Hi John,
On 18/04/2020 12:05, John Murphy wrote:
If I simply '>' the input, which was going
to aplay, to a file, it's
done in a flash. Unplayable, but the file contains data. Could I write
a header first somehow? Or a container format would be OK.
there are for sure "correct" ways to do it. If you want to use pure bash magic
here you are:
Header of a wave file contains 44 byte. To extract it to a file use:
head -c 44 original.wav > header.bin
Now you can use your file from above (let's call it part.raw) and use:
cat header.bin part.raw > newname.wav
You should be able to play the new file. Be aware that the header is correct except for
the length information. You might fix this with
wavfix (https://github.com/agfline/wavfix). Furthermore if your parts are not cut at a
sample boundary (e.g. a normal wav file is stereo 16
bit per channel thus 4 byte per sample) you will get noise.
Gerhard
3:48 a.m.
Hi again,
On 19/04/2020 00:39, Gerhard Zintel wrote:
On 18/04/2020 12:05, John Murphy wrote:
One further remark. The wave header has two length information at byte offset 5 and 41
(see http://www.topherlee.com/software/pcm-tut-wavformat.html). You can use dd like
described
here (https://unix.stackexchange.com/questions/214820/patching-a-binary-with-dd) to patch
the created file newname.wav afterwards to inject the correct length information.
The length information has to be in binary representation. You could use the method
described here
(https://stackoverflow.com/questions/9955020/how-to-write-integer-to-binary-…)
to get the 4 byte representation of file newname.wav
A lot of shell magic but it seems to work.
Gerhard
If I simply '>' the input, which was
going to aplay, to a file, it's
done in a flash. Unplayable, but the file contains data. Could I write
a header first somehow? Or a container format would be OK.
there are for sure "correct" ways to do it. If you want to use pure bash magic
here you are:
Header of a wave file contains 44 byte. To extract it to a file use:
head -c 44 original.wav > header.bin
Now you can use your file from above (let's call it part.raw) and use:
cat header.bin part.raw > newname.wav
You should be able to play the new file. Be aware that the header is correct
except for the length information. You might fix this with
wavfix (https://github.com/agfline/wavfix). Furthermore if your parts are
not cut at a sample boundary (e.g. a normal wav file is stereo 16
bit per channel thus 4 byte per sample) you will get noise. 
4:28 a.m.
On Sat, Apr 18, 2020 at 5:49 PM Gerhard Zintel <gerhard.zintel(a)web.de>
wrote:
One further remark. The wave header has two length information at byte
offset 5 and 41
(see http://www.topherlee.com/software/pcm-tut-wavformat.html). You can
use dd like described
here (
https://unix.stackexchange.com/questions/214820/patching-a-binary-with-dd)
to patch
the created file newname.wav afterwards to inject the correct length
information.
being pedantic just for the sake of it ....
WAV is a subformat of the RIFF file format, which uses a set of "chunks"
with a 4 byte ID and a 4 byte length for each chunk.
Although it is conventional for the various chunks to come in a fairly
standard order (RIFF .. WAV .. FMT), nothing about the standard requires
this, and the correct way to parse any RIFF file (and hence any WAV file)
is chunk by chunk. Making assumptions about byte offsets will work in the
majority of cases, but will break in some.
In addition, the length information at byte 5 (which actually is constant,
since that's the outermost RIFF chunk, is the length of the entire file,
not the WAV data length.
1:18 p.m.
On Sun, 19 Apr 2020 01:48:34 +0200 Gerhard Zintel wrote:
Hi again,
On 19/04/2020 00:39, Gerhard Zintel wrote:
Hi Gerhard,
I thought I might need to abort attempts in that direction, as I used
Audacity to export exactly 5 seconds of audio from one of my files and
then used the player program to output a region of that's entire length
to a new file.
First I noticed the new file is much bigger than the file from Audacity
export, but then I saw it's actually exactly (Audacity_file - 44) * 2
so there's still hope.
Thanks a million for all the help. I had a quick look at using Python
to make files from region information lines. It has a wave module
which has 'setpos' and 'tell' methods which work in frames, so I'll
get there one way or another.
--
John.
On 18/04/2020 12:05, John Murphy wrote:
One further remark. The wave header has two length information at byte offset 5 and 41
(see http://www.topherlee.com/software/pcm-tut-wavformat.html). You can use dd like
described
here (https://unix.stackexchange.com/questions/214820/patching-a-binary-with-dd) to
patch
the created file newname.wav afterwards to inject the correct length information.
The length information has to be in binary representation. You could use the method
described here
(https://stackoverflow.com/questions/9955020/how-to-write-integer-to-binary-…)
to get the 4 byte representation of file newname.wav
A lot of shell magic but it seems to work.
If I simply '>' the input, which was
going to aplay, to a file, it's
done in a flash. Unplayable, but the file contains data. Could I write
a header first somehow? Or a container format would be OK.
there are for sure "correct" ways to do it. If you want to use pure bash magic
here you are:
Header of a wave file contains 44 byte. To extract it to a file use:
head -c 44 original.wav > header.bin
Now you can use your file from above (let's call it part.raw) and use:
cat header.bin part.raw > newname.wav
You should be able to play the new file. Be aware that the header is correct
except for the length information. You might fix this with
wavfix (https://github.com/agfline/wavfix). Furthermore if your parts are
not cut at a sample boundary (e.g. a normal wav file is stereo 16
bit per channel thus 4 byte per sample) you will get noise.
18 Apr
18 Apr
2:48 p.m.
John,
On 18/04/2020 10:50, John Murphy wrote:
I use a program which plays regions of various .wav
files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
You can pipe into lame or oggenc as a possibility and yes, they have to create a header.
You have to advice them to get raw data and give
the header information using the flags.
man lame and man oggenc are your friends.
Gerhard
4:52 p.m.
On Sat, 18 Apr 2020 12:48:31 +0200 Gerhard Zintel wrote:
John,
On 18/04/2020 10:50, John Murphy wrote:
Tried it, thank you. It makes a file, but I presume I have the options
wrong (or I need a compile without 'libsndfile') because the result sounds
awful.
| lame -r -s 48 --little-endian - lame-test.mp3
WARNING: libsndfile may ignore -r and perform fseek's on the input.
Compile without libsndfile if this is a problem.
Assuming raw pcm input file
LAME 3.100 64bits (http://lame.sf.net)
Using polyphase lowpass filter, transition band: 16452 Hz - 17032 Hz
Encoding <stdin> to lame-test.mp3
Encoding as 48 kHz j-stereo MPEG-1 Layer III (12x) 128 kbps qval=3
--
John.
I use a program which plays regions of various
.wav files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
You can pipe into lame or oggenc as a possibility and yes, they have to create a header.
You have to advice them to get raw data and give
the header information using the flags.
man lame and man oggenc are your friends. 
4:09 p.m.
Hi,
maybe I can give you a new view on your problem: If I understand you
right, you want to extract parts of audio files and merge them into a
new file?
Apart from the obvious answer "That is what a DAW does!" [1], maybe
instead of "play parts of files into another file" you can search the
available commands for "extract", "split", "merge" and
"append"? Throw
"convert" into the mix…
[1]: Ardour, audacity and others are gui-tools fulfilling this. I also
remember ecasound and nama
(https://freeshell.de/~bolangi/cgi1/nama.cgi/00home.html) to be command
line DAWs.
Maybe that helps?
- Arnold
Am 18.04.20 um 10:50 schrieb John Murphy:
I use a program which plays regions of various .wav
files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
Thank you.
5:33 p.m.
On Sat, 18 Apr 2020 14:09:22 +0200 Arnold Krille wrote:
Hi,
maybe I can give you a new view on your problem: If I understand you
right, you want to extract parts of audio files and merge them into a
new file?
That's right, but I should explain...
Apart from the obvious answer "That is what a DAW
does!" [1], maybe
instead of "play parts of files into another file" you can search the
available commands for "extract", "split", "merge" and
"append"? Throw
"convert" into the mix…
How well I remember doing so many years ago. There's only one, long
forgotten Windows DAW which works the way I do, but, more recently,
a C programmer (Sed) wrote the utterly brilliant program 'audiotag' *,
with which I can use the pointer right where the zoomed in (by scroll
wheel) visualisation of the wave is and a left click sets a marker,
which can then become the beginning or end of a new region. Right
click plays from that marker (or stops, if playing).
A new line of information is output when a new region is created and
those lines can be assembled into a playlist file. They look like:
REGION "/home/john/0WAVs/louder/Fri0304.wav" 00:00:01.14181 00:00:05.07359
(saved 2020 04 18 T 10 40 25)
Having tried sox and lame using the 'dump' program (which Sed gave
me to play the regions) via aplay - I think you're right that a new
approach would be better. Could parse those lines in Python :)
* http://sed.free.fr/audiotag/ (although 'dump' isn't with it)
[1]: Ardour, audacity and others are gui-tools
fulfilling this. I also
remember ecasound and nama
(https://freeshell.de/~bolangi/cgi1/nama.cgi/00home.html) to be command
line DAWs.
Maybe that helps?
It does. Thank you.
--
John.
19 Apr
19 Apr
2:30 p.m.
Sat, 18 Apr 2020 09:50:30 +0100 - John Murphy <rosegardener(a)freeode.co.uk>uk>:
I use a program which plays regions of various .wav
files. Its
output pipes into aplay like: '| aplay -f FLOAT_LE -c 2 -r 48000'
To where can I pipe its output, instead, to make a new .wav file,
or make a compressed file? Preferably faster than the region(s)
take to play.
Or, if not, make aplay write to a file instead of playing?
Thank you.
Use sox:
sox source.wav -L -c 2 -r 48000 new.wav trim <start_second>
<duration_seconds>
where:
-L : little endian
-c 2 : 2-channels stereo
-r 48000 : freq (Hz)
<start_second> : region start (second)
<duration_seconds> : region duration (seconds)
Regards
--
al3xu5
Say NO to copyright, patents, trademarks and any industrial design restrictions.
________________________________________________________________________________
Public GPG/PGP key
ID: 4096 bit RSA key F94CFE23
Fingerprint: 59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23
1476
days inactive
1477
days old
linux-audio-user@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
al3xu5 / dotcommon -
Arnold Krille -
Gerhard Zintel -
John Murphy -
Paul Davis -
Will Godfrey