Decoding data with random offset

Jun 21, 2010 at 2:12 AM

Hello,

My app is receiving the speex narrowband (160 bytes frames and 40 bytes subframes) encoded audio in chunks of 20 bytes.

The problem is. This is a continuous stream of data, and currently I don't know where a frame begins or ends.

The first byte I send to the decoder can be from beginning of the frame (which would be optimal), or from the second half of a subframe (worst case).

I don't know which will be.

Is it possible to decode this audio in such conditions?

I am not concerned with the first frame, I hope de decoder can catch up and decode the subsequent frames.

Thanks in advance
Jader Dias

Coordinator
Jun 21, 2010 at 6:37 AM
Edited Jun 21, 2010 at 6:37 AM

Hi Jader,

I have never come accross such an requirement since normally you would pack n frames into a container packet and transmit or store in somewhere. Later you could use this container to split the contained data into the original frame (even in VBR mode).

Which version of Speex are you using since the NSpeex version is based on Speex 1.0.3 but the bitstream format of Speex has been frozen in version 1.1 so there might be a problem when using the NSpeex port published here.

Have you had a look at the following link: http://www.speex.org/docs/manual/speex-manual/node10.html#cap:bits-narrowband which describes the narrowband bit-allocation more in detailed.

Another (a more hands on) approach would be to fill the decoder buffer with every 20 samples (I guess you are talking about 160 samples per frame and 20 samples per subframe not Bytes) as you receive them and then try to decode it. Once you get a positive (meaning 0 as a return code) result from the call to decode you are in sync. I haven't tried it so this would be just a quick test and if it doesn't work you could start with investigating the bit stream.

Christoph

Jun 22, 2010 at 12:25 AM
Hi Balistof,

I forgot for a moment that each sample uses 16 bit and thus each
decoded frame uses 320 bytes. Thank you for your explanation.
I'll try your suggestion.

Best regards,

Jader Dias

On Mon, Jun 21, 2010 at 3:37 AM, [email removed] wrote:
> From: balistof
>
> Hi Jader,
>
> I have never come accross such an requirement since normally you would pack
> n frames into a container packet and transmit or store in somewhere. Later
> you could use this container to split the contained data into the original
> frame (even in VBR mode).
>
> Which version of Speex are you using since the NSpeex version is based on
> Speex 1.0.3 but the bitstream format of Speex has been frozen in version 1.1
> so there might be a problem when using the NSpeex port published here.
>
> Have you had a look at the following
> link: http://www.speex.org/docs/manual/speex-manual/node10.html#cap:bits-narrowband which
> describes the narrowband bit-allocation more in detailed.
>
> Another (a more hands on) approach would be to fill the decoder buffer with
> every 20 samples (I guess you are talking about 160 samples per frame and 20
> samples per subframe not Bytes) as you receive them and then try to decode
> it. Once you get a positive result from the call to decode you are in sync.
> I haven't tried it so this would be just a quick test and if it doesn't work
> you could start with investigating the bit stream.
>
> Christoph
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe on CodePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at CodePlex.com