8 Nov
2016
8 Nov
'16
2:05 p.m.
On 07.11.2016 11:32, J. C. wrote:
libsndfile is not the limiting factor. It's the wav format that doesn't
support large files.
(The "raw" format is also handled by libsndfile, but again, libsndfile is
not to blame here,
so that doesn't matter.)
Hey hey,
I tried to record over long periods of time (7-9 hours), using jack_rec,
which
apparently relies on libsndfile for writing
audiofiles. I started out
using
.wav, which broke off after 6:12:49 (2.1G). Next
time, I tried using the
file
extension .w64, which yielded the same result.
So, which format, or extension, would work for such periods of time?
Have you tried with jack_capture?
It uses libsndfile, too for codecs, but can dump raw samples to disk if
you tell
it to.
So, if libsndfile should be the limiting factor, try dumping the raw
frames and
later analyze those.
jack_capture -f raw -b FLOAT snoring.bin
Besides this option (and -f w64 and -f CAF which has been suggested),
jack_capture continue writing to new files in case you try to write more
data than
is supported, so you can even use the default wav format for large files.
8 Nov
8 Nov
2:15 p.m.
New subject: Using commandline app to mark/detect sounds above a threshold
On Mon, 7 Nov 2016 11:32:55 +0100 (CET), J. C. wrote:
I started out using .wav, which broke off after
6:12:49
(2.1G). Next time, I tried using the file extension .w64, which
yielded the same result.
On Tue, 8 Nov 2016 15:05:24 +0100, Kjetil Matheussen wrote:
libsndfile is not the limiting factor. It's the wav
format that doesn't
support large files.
The English Wiki disagrees with your claim that w64 files are limited
to 2.1G(B, the Wiki likely mean GiB, the OP perhaps GB), even wav seems
not to be limited to 2.1G(B|GiB).
"Limitations
The WAV format is limited to files that are less than 4 GB, because of
its use of a 32-bit unsigned integer to record the file size header
(some programs limit the file size to 2 GB).[note 1] Although this is
equivalent to about 6.8 hours of CD-quality audio (44.1 kHz, 16-bit
stereo), it is sometimes necessary to exceed this limit, especially
when greater sampling rates, bit resolutions or channel count are
required. The W64 format was therefore created for use in Sound Forge.
Its 64-bit header allows for much longer recording times. The RF64
format specified by the European Broadcasting Union has also been
created to solve this problem." -
https://en.wikipedia.org/wiki/WAV#Limitations
Regards,
Ralf
2:59 p.m.
New subject: Using commandline app to mark/detect sounds above a threshold
The English Wiki disagrees with your claim that w64
files are limited
to 2.1G(B, the Wiki likely mean GiB, the OP perhaps GB), even wav seems
not to be limited to 2.1G(B|GiB).
I did not claim either of this.
3:19 p.m.
New subject: Using commandline app to mark/detect sounds above a threshold
On Tue, 8 Nov 2016 15:59:27 +0100, Kjetil Matheussen wrote:
The OP claims that no files larger than 2.1G were produced when using
libsndfile.
On Tue, 8 Nov 2016 15:05:24 +0100, you claimed:
The English
Wiki disagrees with your claim that w64 files are limited
to 2.1G(B, the Wiki likely mean GiB, the OP perhaps GB), even wav
seems not to be limited to 2.1G(B|GiB).
I did not claim either of this. libsndfile is not the limiting factor. It's the wav
format that doesn't
support large files.
In the context your claim actually is, that the wav formats are the
culprit. Regarding the Wiki, for what the OP wants to get, the
limitation is not caused by the two wav formats.
However, it doesn't matter what you wanted to point out, important only
is that, if neither libsndfile, nor wav does cause the issue the OP
experienced, then something else most cause the trouble. Right?
Regards,
Ralf
3:38 p.m.
New subject: Using commandline app to mark/detect sounds above a threshold
The OP claims that no files larger than 2.1G were
produced when using
libsndfile.
Are you trolling? OP did not claim that libsndfile was to blame.
No one has. Don't try to twist what people write so that it
sounds like something else.
However, it doesn't matter what you wanted to
point out, important only
is that, if neither libsndfile, nor wav does cause the
issue the OP
experienced, then something else most cause the trouble. Right?
I don't know why it stopped at 2GB. Maybe it's something in the jackrec
program, but that's unrelated since we were talking about jack_capture,
not jackrec. And in jack_capture, the limit is 4GB (jack_capture also uses
libsndfile). I know this quite well since I'm the author of
jack_capture, and I've
tested the 4GB barrier many times to ensure jack_capture handles it correctly.
3:50 p.m.
New subject: Using commandline app to mark/detect sounds above a threshold
On Tue, 8 Nov 2016 16:38:21 +0100, Kjetil Matheussen wrote:
Are you trolling? I didn't claim that! [1]
So we still don't know the cause of the issue. That's all I want to
know.
Regards,
Ralf
[1]
If you read your original mail, then the OP pointed out that the wav
files were not larger than 2.1GB and that libsndfile was used. You
claim that wav is the limiting factor:
On Tue, 8 Nov 2016 15:05:24 +0100, Kjetil Matheussen wrote:
The OP claims
that no files larger than 2.1G were produced when
using
libsndfile.
Are you trolling? OP did not claim that libsndfile was to blame. No one has. Don't try to twist what people write so
that it
sounds like something else.
You do, I don't. I only want to learn what does cause the issue, to
avoid, that the same happens to friends or me, if we need to record for
such a long time, too.
Anyway, what could have been the culprit?
However, it
doesn't matter what you wanted to point out, important
only
is that, if neither libsndfile, nor wav does
cause the issue the OP
experienced, then something else most cause the trouble. Right?
I don't know why it stopped at 2GB. Maybe it's something in the jackrec
program, but that's unrelated since we were talking about jack_capture,
not jackrec. And in jack_capture, the limit is 4GB (jack_capture also
uses
libsndfile). I know this quite well since I'm the author of
jack_capture, and I've
tested the 4GB barrier many times to ensure jack_capture handles it
correctly.
On 07.11.2016 11:32, J. C. wrote:
libsndfile is not the limiting factor. It's the wav format that doesn't
support large files.
(The "raw" format is also handled by libsndfile, but again, libsndfile
is not to blame here,
so that doesn't matter.)
Hey hey,
I tried to record over long periods of time (7-9 hours), using
jack_rec,
which
apparently relies on libsndfile for writing
audiofiles. I started
out
using
.wav, which broke off after 6:12:49 (2.1G). Next
time, I tried
using the
file
extension .w64, which yielded the same result.
So, which format, or extension, would work for such periods of
time?
Have you tried with jack_capture?
It uses libsndfile, too for codecs, but can dump raw samples to disk
if you tell
it to.
So, if libsndfile should be the limiting factor, try dumping the raw
frames and
later analyze those.
jack_capture -f raw -b FLOAT snoring.bin
Besides this option (and -f w64 and -f CAF which has been suggested),
jack_capture continue writing to new files in case you try to write
more data than
is supported, so you can even use the default wav format for large
files.
2757
days inactive
2757
days old
linux-audio-user@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
Kjetil Matheussen -
Ralf Mardorf