Vorbis - Jan 2003 - [fwd] help encoding low-quality audio please

Apologies; a filter mistriggered on the original send of this message.

Monty

Date: Fri, 10 Jan 2003 01:11:16 -0500 (EST)
Message-Id: <200301100611.BAA12395@biohazard-cafe.mit.edu>
To: vorbis@xiph.org
From: ben-extra@MIT.EDU
Subject: 

Hi,

I am hoping for some guidance.  I have a *bunch* of audio in the form of
realaudio streams.  As is, they are of a quality similar to fair AM
quality.  They are of large sentimental value.  I have read the archives
back through November, and I am following the recent "lo-fi sound"
thread, but I am still left with questions.

What I have started to do so far is to use vsound to convert the 12.5
Kbps streams to .au files.  The files that result are by default created
as 16 bit, 11025 samples/second.  Thus, a typical (for me) 3 hour
recording is very roughly 500 MB.  I want to compress these and burn
them to CD.  My goal is to have them for many years (yes, I know I will
have to watch media degradation).

Thus, a bunch of questions.

Question 1) I know this is probably the wrong place to ask for a
dissenting view, but are these .ogg files going to be easily readable in
10 years?  It seems like .ogg has reached critical mass, and it seems
(from what I have read) that the format's specification will be stable,
but I would like to ask.  mp3 is the obvious alternative.  I prefer
Vorbis compression on "moral" grounds, but not if there are reasons
for
choosing another format.

I did some test encodings to see what sort of space I might save, with
the following results (sizes in kilobytes).  All this was done with
OggEnc v1.0 (libvorbis 1.0) on a Debian woody system.

25872 test.au
24820 test.wav
 2768 test_from_wav_q5.ogg
 2304 test_q1.ogg
 2960 test_q3.ogg
 3624 test_q5.ogg
 3968 test_q6.ogg

test.au is my original 10 minute long sample.  test_q1.ogg, test_q3.ogg,
test_q5.ogg, and test_q6.ogg were produced with commands such as:
OggEnc --raw --raw-rate 11025 -q5 test.au
with q values of 1,3, 5, and 6 respectively.

Now an odd thing.  test_q5.ogg took about 1 minute to encode.  If I
first convert the .au file to .wav (using sox) and then encode it, using:
OggEnc -q5 test.wav

I naively expected similar output file sizes.  As you can see, the file,
test_from_wav_q5.ogg is instead 25% smaller than test_q5.ogg, although
it took about 75% (1 minute, 45 seconds total) longer to encode.

Question 2) Why am I getting such a smaller file size when encoding from
the .wav file?  It seems like I am getting something for nothing, and I
get nervous when that happens.

Question 3) This is my most important question.  Due to their size, I
can't keep the raw files.  But these recording are something I would
like to enjoy in the years ahead.  The computer I am doing this on has
lousy sound, and I don't trust my ears a whole lot to start with.  I
also have read, in the FAQ, about the inherent problems of going from
source->lossy compression->uncompressed->lossy compression, as I am.  I
would like to make the best of my situation.  What "q" level would be
a
conservative choice to use with the encoder?  I would rather have larger
files than save every last MB I can.  Also, are there any other command
line options I should be using?  Any and all thoughts on how to best use
OggEnc will be greatly appreciated.

Question 3a) Feeding 11025 Hz files to OggEnc is now ok, yes?  I know
OggEnc used to be optimized for 44100, and had troubles with lower
bitrates.

Thank you in advance to all who help out,

Ben Blout

<p>----- End forwarded message -----
--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Monty> Question 3) This is my most important question.  Due to their size, I
Monty> can't keep the raw files.  But these recording are something I
would
Monty> like to enjoy in the years ahead.  The computer I am doing this on has
Monty> lousy sound, and I don't trust my ears a whole lot to start with. 
I
Monty> also have read, in the FAQ, about the inherent problems of going from
source->>lossy compression->uncompressed->lossy compression, as I
am.  I
Monty> would like to make the best of my situation.  What "q" level
would be a
Monty> conservative choice to use with the encoder?  I would rather have
larger
Monty> files than save every last MB I can.  Also, are there any other
command
Monty> line options I should be using?  Any and all thoughts on how to best
use
Monty> OggEnc will be greatly appreciated.

FLAC is not an alternative? Or may be zipping or bziping it.

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

('binary' encoding is not supported, stored
as-is)
> Question 1) I know this is probably the wrong place to ask for a
> dissenting view, but are these .ogg files going to be easily readable in
> 10 years?
As long as there are people using it, it will be readable.
More detailed: as long as there's someone programming C (it is in C, right?)
and compilers for the computers used at this time, it is possible to adapt it
to new cpu-architectures.
Even more detailed: as long as there's somebody willing to write a reader,
it
will be readable.

These are the advantages of a Free and Open Standard. (And a Free Source Code)

-- Daniel

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.