2 Apr
2013
2 Apr
'13
8:18 p.m.
I have a series of wave files that I want to combine into one long mp3 and
flac. I have checked each file individually, and I'm convinced that I've
confirmed my previous notion that these files combined last a total of just
above 12 hours.
Now, normally I've been using sox to combine the wave files, and using the
result in lame and flac to create the result files, but in this instance
I'm getting wrong results. A normal run creates a wave file (and resultant
mp3) of just above 5 hours. I figured this might be because of a limitation
in the wave headers, so I made sox output to a w64 file instead. Now both
the wave and result mp3 turned out at 18+ hours. Any idea why sox is
getting a wrong result here? Do I need to tell it that the input files are
regular wave?
When I tried to pipe the output, like this:
sox 01.wav 02.wav -t wav - | lame - result.mp3 (or something like that)
the file turned out at only 2+ hours, while
sox 01.wav 02.wav -t raw - | lame -r -s 44.1 - result.mp3
turned out a 56 hour file.
Nevertheless, I think I'm on to something with the last command, but I
might have misunderstood some sox or lame documentation. Tips?
Arve
2 Apr
2 Apr
8:35 p.m.
Regular WAV at ~CD rate is limited to about 5 hours because the length
encoding fields are 32 bit. You need to generate an extended WAV with
the WAVEFORMATEXTENSIBLE struct that allows a 16 exabyte data chunk.
I'm a little surprised sox doesn't do that by default.
Monty
9:12 p.m.
On Tue, Apr 2, 2013 at 2:35 PM, Monty Montgomery <xiphmont(a)gmail.com> wrote:
Regular WAV at ~CD rate is limited to about 5 hours
because the length
encoding fields are 32 bit. You need to generate an extended WAV with
the WAVEFORMATEXTENSIBLE struct that allows a 16 exabyte data chunk.
I'm a little surprised sox doesn't do that by default.
I wasn't aware that WAVEFORMATEXTENSIBLE covered file sizes - the spec
seems to be mostly about "higher resolution" sample formats. what did i
miss?
more portable solutions, i think, include using w64 format or even CAF,
which are both defined with (unsigned) 64 bit file size limits.
--p
9:15 p.m.
On Tue, Apr 2, 2013 at 3:12 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Tue, Apr 2, 2013 at 2:35 PM, Monty Montgomery <xiphmont(a)gmail.com>wrote;wrote:
Specifically:
"The WAVE_FORMAT_EXTENSIBLE format code indicates that there is an
extension to the Format chunk. The extension has one field which declares
the number of "valid" bits/sample (wValidBitsPerSample). Another field (
dwChannelMask) contains a bits which indicate the mapping from channels to
loudspeaker positions. The last field (SubFormat) is a 16-byte globally
unique identifier (GUID)."
it does not change the size of the size field of the RIFF or data chunks,
which is what matters here.
Regular WAV at ~CD rate is limited to about 5
hours because the length
encoding fields are 32 bit. You need to generate an extended WAV with
the WAVEFORMATEXTENSIBLE struct that allows a 16 exabyte data chunk.
I'm a little surprised sox doesn't do that by default.
I wasn't aware that WAVEFORMATEXTENSIBLE covered file sizes - the spec
seems to be mostly about "higher resolution" sample formats. what did i
miss?
9:24 p.m.
Huh, you're right.
Oh, i see... we've been supporting >4GB wave files in the Xiph stuff
by setting the length to 0xFFFFFFFF and assuming the data chunk is
last (intuiting chunk length from file length).
Monty
9:29 p.m.
On Tue, Apr 2, 2013 at 3:24 PM, Monty Montgomery <xiphmont(a)gmail.com> wrote:
Huh, you're right.
Oh, i see... we've been supporting >4GB wave files in the Xiph stuff
by setting the length to 0xFFFFFFFF and assuming the data chunk is
last (intuiting chunk length from file length).
nothing about RIFF implies that the data chunk is last. in fact, there is
no ordering at all except that the RIFF chunk is first. there are several
windows app that make this "mistake".
w64 is the format to use, and libsndfile handles it (and CAF) with
distinction.
10:22 p.m.
nothing about RIFF implies that the data chunk is
last.
Correct. However the standard hack to use WAV in streaming
applications is to put DATA last and set the chink size to 0xffffffff.
w64 is the format to use, and libsndfile handles it
(and CAF) with
distinction.
Yay, good.
Monty
10:24 p.m.
On 2 April 2013 21:29, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Tue, Apr 2, 2013 at 3:24 PM, Monty Montgomery <xiphmont(a)gmail.com>wrote;wrote:
I guess this is a bug in sox then. If I use sndfile-concat (by first
turning the first wave file into w64), a correct w64 is made, and if I use
sndfile-salvage on the wave sox produced (the one with too much sound for
the header to explain) a correct file is also made. Either way, success!
Thanks for the insight guys.
Huh, you're right.
Oh, i see... we've been supporting >4GB wave files in the Xiph stuff
by setting the length to 0xFFFFFFFF and assuming the data chunk is
last (intuiting chunk length from file length).
nothing about RIFF implies that the data chunk is last. in fact, there is
no ordering at all except that the RIFF chunk is first. there are several
windows app that make this "mistake".
w64 is the format to use, and libsndfile handles it (and CAF) with
distinction.
3 Apr
3 Apr
12:42 a.m.
Monty Montgomery wrote:
Huh, you're right.
Oh, i see... we've been supporting >4GB wave files in the Xiph stuff
by setting the length to 0xFFFFFFFF and assuming the data chunk is
last (intuiting chunk length from file length).
Yes, thats a horrible hack that makes me cringe even to think about
it :-).
libsndfile supports a couple file file formats that support > 4Gig
files eg RF64, W64 and CAF.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
4282
days inactive
4282
days old
linux-audio-user@lists.linuxaudio.org
8 comments
4 participants
participants (4)
-
Arve Barsnes -
Erik de Castro Lopo -
Monty Montgomery -
Paul Davis