On Nov 02 01:57:01, [email protected] wrote:
> https://sourceforge.net/tracker/?func=detail&atid=110706&aid=3582634&group_id=10706
> mp3 to wav conversion while using piping to output instead of writing to file
> doesn't work as expected
>
> How to reproduce error:
>
> $: sox Slipknot\ -\ Psychosocial.mp3 -t wav psychosocial2.wav
> $: sox Slipknot\ -\ Psychosocial.mp3 -t wav - | cat > psychosocial.wav
> $: diff psychosocial.wav psychosocial2.wav
> Binary files psychosocial.wav and psychosocial2.wav differ
This must be one of the best Useless Uses Of Cat that I have seen.
In fact, it looks like the piping through cat(1) is actually
what's making the difference!
$ sox file.mp3 one.wav
$ sox file.mp3 -t wav - > two.wav
$ sox file.mp3 -t wav - | cat > three.wav
$ diff one.wav two.wav
$ diff one.wav three.wav
Binary files one.wav and three.wav differ
So the wav output file is the same if you just redirect it,
and is not the same if you uselessly pipe it through cat.
Which puzzles me a bit.
All of the three resulting files are of the same size.
$ ls -l *wav
-rw-r--r-- 1 hans wheel 442412 Nov 2 11:25 one.wav
-rw-r--r-- 1 hans wheel 442412 Nov 2 11:59 three.wav
-rw-r--r-- 1 hans wheel 442412 Nov 2 11:59 two.wav
Here are the wav headers of one.wav and three.wav (hexdumped
on a little endian machine). They do not differ anywhere else.
$ hexdump -C one.wav | head -4
00000000 52 49 46 46 24 c0 06 00 57 41 56 45 66 6d 74 20 |RIFF$...WAVEfmt |
00000010 10 00 00 00 01 00 02 00 80 bb 00 00 00 ee 02 00 |................|
00000020 04 00 10 00 64 61 74 61 00 c0 06 00 00 00 00 00 |....data........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
$ hexdump -C three.wav | head -4
00000000 52 49 46 46 24 d2 06 00 57 41 56 45 66 6d 74 20 |RIFF$...WAVEfmt |
00000010 10 00 00 00 01 00 02 00 80 bb 00 00 00 ee 02 00 |................|
00000020 04 00 10 00 64 61 74 61 00 d2 06 00 00 00 00 00 |....data........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
If I am reading the wav header right, they differ in the size field
of the riff header (24 c0 06 00 vs 24 d2 06 00) and in the size field
of the "data" subchunk (00 c0 06 00 vs 00 d2 06 00).
For one.wav (the direct sox output file), both of the fields are correct:
file size minus the first 8 bytes is 24 c0 06 00 = 442404 = 442412 - 8;
data chunk size is 00 c0 06 00 = 442368 = 442412 - 44 bytes of the header.
For three.wav (the piped output file), both fields are
00d2 - 00c0 = 4608 bytes more than they should be.
> Investigating with a hex editor, it appears certain bytes which should
> be output as "6E" get output as "80" when piped.
You don't provide details, so I will bluntly assume that these differences
are in the same position in the wav header as in my example (and your
machine is little endian as mine) and just note that the difference
between 006e and 0080 is (dec) 4608 too.
Question is how.
cat surely doesn't do anything to the data.
SoX is just writing to stdout and has no knowledge about
its stdout being either redirected (to two.wav) or piped (to cat > three.wav)
later, right? Can someone please shed some light on what difference is it
to sox in this (regarding length probably)?
$ sox file.mp3 -t wav - > two.wav
$ sox file.mp3 -t wav - | cat > three.wav
Jan
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
SoX-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sox-devel
