Vorbis - Mar 2009 - smallest page of encoded data

Hi,

I am implementing and audio recorder where I need to encode to vorbis DURING
recording.
I need to allow the user to cut and paste segments of encoded audio into a new
stream.
As such, I need to encode the audio in sub-second pages (the smallest allowable
amount for the wave format), so that cut/paste can be implemented simply by
re-arranging these encoded pages.

How can I calculate, the minimum number of PCM bytes required so that
vorbis_analysis_blockout will return 1 and give me the full page in vorbis
encoded form?
This will be my 'edit resolution', the smallest portion of audio that
can be manipulated by any cut/copy/paste operation.

Thanks for your help

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alangley at winscribe.com
www.winscribe.com
?
?

On Sun, Mar 15, 2009 at 7:37 PM, Adam Langley <alangley at
winscribe.com>wrote:
> Hi,
>
> I am implementing and audio recorder where I need to encode to vorbis
> DURING recording.
> I need to allow the user to cut and paste segments of encoded audio into a
> new stream.
> As such, I need to encode the audio in sub-second pages (the smallest
> allowable amount for the wave format), so that cut/paste can be implemented
> simply by re-arranging these encoded pages.

Somebody with more knowledge of Vorbis internals will probably correct me if
I'm wrong, but I don't think it's going to be that simple. Vorbis
uses an
overlap transform in which the signal is shaped by a rising and falling
envelope prior to being encoded. To reconstruct the audio, you need the
falling slope of one block and the rising slope of the following block,
which are overlapped such that they can be added together to yield the
original waveform. This makes it fundamentally difficult to perform cut and
paste by "simply" rearranging blocks. (Unless you're okay with the
"cross-fade" artifacts that you'll most likely get by allowing a
block to be
followed by a block with which it's not intended to fit together.)

-Carsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/vorbis/attachments/20090315/c619abbb/attachment.htm

I could do that, but then to merge the final result into a single file I would
need to decode each chunk, concatenate them, and re-encode them again...
actually resulting in more overall work and kind of defeating the purpose...

Adam Langley
Senior Developer
Tel: +64 9 486 9010
alangley at winscribe.com
www.winscribe.com
?
?


-----Original Message-----
From: Ben B [mailto:bdbnew at MIT.EDU] 
Sent: Monday, 16 March 2009 4:37 p.m.
To: Adam Langley
Subject: Re: [Vorbis] smallest page of encoded data
>Date: Mon, 16 Mar 2009 14:43:10 +1300
>From: "Adam Langley" <alangley at winscribe.com>
>
>Thanks for the insight Carsten.
>Basically, we're building a dictation system, with SPEEX at its core.
Curre>ntly we have this working but the problem is, the SPEEX encoding
process ta>kes approximately 1 minute per MB of PCM audio, resulting in
lengthy 'encod>e' jobs after a user has finished their dictation.
>I am attempting to find a way around this, and my hope was that I could
per>form some type of incremental encode during the record process, yet still
e>nable the user to trim/rearrange their dictation without requiring a
comple>te re-encode.
>And most users do edit the file to some degree...
Well, I'm no expert on ogg or speex encoders.

How about taking each 1/4 second, and encoding it a separate file.  Then
you could allow editting down to 1/4 second chunks.

-Ben
>Adam Langley
>Senior Developer
>Tel: +64 9 486 9010
>alangley at winscribe.com
>www.winscribe.com
>=A0
>=A0
>
>From: vorbis-bounces at xiph.org [mailto:vorbis-bounces at xiph.org] On
Behalf Of> Carsten Haese
>Sent: Monday, 16 March 2009 2:08 p.m.
>To: vorbis at xiph.org
>Subject: Re: [Vorbis] smallest page of encoded data
>
>On Sun, Mar 15, 2009 at 8:27 PM, Adam Langley <alangley at
winscribe.com> wrot>e:
>My end-goal is actually to do this with the SPEEX codec, but I'm using
>Vorbis for now because I have previous experience with it. Am I going to
>have the same problem with SPEEX?
>
>You're going to have a different but equally insurmountable problem.
Speex >is a CELP-based codec. The LP stands for "Linear
Prediction", which means t>hat each frame depends on the history of
frames that came before it. This i>n turn means that you can't rearrange
frames without introducing artifacts.
>
>By the way, you're not saying what kind of audio you're planning to
encode,> so it should be noted that Speex is purely designed to encode human
speech>. It's very good at that, but It will perform poorly if you try to
encode m>usic or other sounds with it.
>
>-Carsten
>_______________________________________________
>Vorbis mailing list
>Vorbis at xiph.org
>http://lists.xiph.org/mailman/listinfo/vorbis