[Vorbis] smallest page of encoded data

Adam Langley alangley at winscribe.com
Sun Mar 15 20:50:44 PDT 2009


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


More information about the Vorbis mailing list