Vorbis dev - Mar 2005 - Streams with block sizes 4096 and 8192

Hello,



I am looking for Ogg-vorbis streams with block sizes 4096 and 8192.
Please let me how do generate these streams. This is to test our
fixed-point implementation...



Best regards

Kiran







Confidentiality Notice

The information contained in this electronic message and any attachments to this
message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20050301/d3604fcd/attachment.html

Hi Kiran,

AFAIK, there are unfortunately no test streams available and also no way 
to force the reference encoder to use specific features or parameters.

Tor


kiran.aral@wipro.com schrieb:
> Hello,
>
> I am looking for Ogg-vorbis streams with block sizes 4096 and 8192. 
> Please let me how do generate these streams. This is to test our 
> fixed-point implementation?
>
> Best regards
>
> Kiran
>

On Tue, Mar 01, 2005 at 03:44:37PM +0530, kiran.aral@wipro.com
wrote:
> 
> Hello,
> 
> 
> 
> I am looking for Ogg-vorbis streams with block sizes 4096 and 8192.
> Please let me how do generate these streams. This is to test our
> fixed-point implementation...
The reference encoder (1.0+) uses a 4096 blocksize for quality
settings less than zero (eg, -q -1).  I'm not aware of any encoder
producing 8192-sized blocks, but I can produce one easily and will do
so tonight.

Monty

Monty,

I would suggest not to include 8192 blocksize altogether. We have taken the
current Encoder setup as the reference to decide about the tables. This will
increase ROM requirement by 16 KB on the Decoder side. If Vorbis wants to have
good presence in Audio market, memory and complexity requirement on Decoder
should be kept to minimum.

One more thing, we have tried to use only 16 MSBs of current 32-bit window
lookup tables and the quality of decoded outputs seems to be not affected. What
was your experience? I am sure you must have experimented with lower precision
of these tables. If it works, it will reduce table requirement by half.

Cheers,
Kumar.

-----Original Message-----
From: Monty [mailto:xiphmont@xiph.org]
Sent: Wednesday, March 02, 2005 4:26 AM
To: kiran.aral@wipro.com
Cc: vorbis-dev@xiph.org
Subject: Re: [Vorbis-dev] Streams with block sizes 4096 and 8192





On Tue, Mar 01, 2005 at 03:44:37PM +0530, kiran.aral@wipro.com
wrote:
> 
> Hello,
> 
> 
> 
> I am looking for Ogg-vorbis streams with block sizes 4096 and 8192.
> Please let me how do generate these streams. This is to test our
> fixed-point implementation...
The reference encoder (1.0+) uses a 4096 blocksize for quality
settings less than zero (eg, -q -1).  I'm not aware of any encoder
producing 8192-sized blocks, but I can produce one easily and will do
so tonight.

Monty
_______________________________________________
Vorbis-dev mailing list
Vorbis-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/vorbis-dev

Hello All,

As Kumar mentioned, Block size of 8192 would definitely increase memory
requirements for decoder implementation. Thanks Kumar, for mentioning
this in this forum. I also emphasize the low memory requirements and
less complexity on the decoder side would increase Vorbis' presence in
audio market especially in portable player market.

I also suggest Vorbis project to draft an amendment by removing 4096 and
8192 block sizes for Vorbis implementation on embedded platforms
provided there are no definite advantages.

Please provide your thoughts on this...

Best regards
Kiran


-----Original Message-----
From: vorbis-dev-bounces@xiph.org [mailto:vorbis-dev-bounces@xiph.org]
On Behalf Of KumarBraj Bhushan
Sent: Wednesday, March 02, 2005 10:32 AM
To: Monty
Cc: vorbis-dev@xiph.org
Subject: RE: [Vorbis-dev] Streams with block sizes 4096 and 8192

Monty,

I would suggest not to include 8192 blocksize altogether. We have taken
the current Encoder setup as the reference to decide about the tables.
This will increase ROM requirement by 16 KB on the Decoder side. If
Vorbis wants to have good presence in Audio market, memory and
complexity requirement on Decoder should be kept to minimum.

One more thing, we have tried to use only 16 MSBs of current 32-bit
window lookup tables and the quality of decoded outputs seems to be not
affected. What was your experience? I am sure you must have experimented
with lower precision of these tables. If it works, it will reduce table
requirement by half.

Cheers,
Kumar.

-----Original Message-----
From: Monty [mailto:xiphmont@xiph.org]
Sent: Wednesday, March 02, 2005 4:26 AM
To: kiran.aral@wipro.com
Cc: vorbis-dev@xiph.org
Subject: Re: [Vorbis-dev] Streams with block sizes 4096 and 8192





On Tue, Mar 01, 2005 at 03:44:37PM +0530, kiran.aral@wipro.com
wrote:
>
> Hello,
>
>
>
> I am looking for Ogg-vorbis streams with block sizes 4096 and 8192.
> Please let me how do generate these streams. This is to test our
> fixed-point implementation...
The reference encoder (1.0+) uses a 4096 blocksize for quality
settings less than zero (eg, -q -1).  I'm not aware of any encoder
producing 8192-sized blocks, but I can produce one easily and will do
so tonight.

Monty
_______________________________________________
Vorbis-dev mailing list
Vorbis-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/vorbis-dev
_______________________________________________
Vorbis-dev mailing list
Vorbis-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/vorbis-dev



Confidentiality Notice

The information contained in this electronic message and any attachments to this
message are intended
for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.

>If we did remove 8196 (and I'm not saying we would), we _certainly_
>wouldn't even consider removing 4096 - that's in wide use, and has
>been for some years. Removing it would break a lot of files that users
>are happily playing at the moment.
Mike you are probably right that 4096 block size is often used for low quality
(q -1) cases. So we might need to keep it for some time. But 8192 can be,
certainly, gotten rid off. If we maintain that future Encoders will not be using
8192 blocksize (as is the case with current Encoder!), this will have no
compatibilty issue.

regards,
Kumar.



-----Original Message-----
From: Michael Smith [mailto:mlrsmith@gmail.com]
Sent: Wednesday, March 02, 2005 11:11 AM
To: kiran.aral@wipro.com
Cc: vorbis-dev@xiph.org
Subject: Re: [Vorbis-dev] Streams with block sizes 4096 and 8192


On Wed, 2 Mar 2005 11:01:42 +0530, kiran.aral@wipro.com
<kiran.aral@wipro.com> wrote:
> 
> Hello All,
> 
> As Kumar mentioned, Block size of 8192 would definitely increase memory
> requirements for decoder implementation. Thanks Kumar, for mentioning
> this in this forum. I also emphasize the low memory requirements and
> less complexity on the decoder side would increase Vorbis' presence in
> audio market especially in portable player market.
> 
> I also suggest Vorbis project to draft an amendment by removing 4096 and
> 8192 block sizes for Vorbis implementation on embedded platforms
> provided there are no definite advantages.
If we did remove 8196 (and I'm not saying we would), we _certainly_
wouldn't even consider removing 4096 - that's in wide use, and has
been for some years. Removing it would break a lot of files that users
are happily playing at the moment.

I don't think removing 8196 is really something we'd want to do either
- as a concession to limited-memory devices, the final format
specification (as finalised when we did the libvorbis 1.0 release)
removed several larger block sizes that had previously been permitted
(I think these were 16k, 32k, and 64k).

I don't think we want to retroactively change the vorbis format (for a
future "vorbis 2", we'd certainly be willing to consider any sort
of
changes, though).

Mike
_______________________________________________
Vorbis-dev mailing list
Vorbis-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/vorbis-dev

>Message: 4
>Date: Wed, 2 Mar 2005 16:40:35 +1100
>From: Michael Smith <mlrsmith@gmail.com>
>Subject: Re: [Vorbis-dev] Streams with block sizes 4096 and 8192
>To: "kiran.aral@wipro.com" <kiran.aral@wipro.com>
>Cc: vorbis-dev@xiph.org
>Message-ID: <3c17372105030121401dc18284@mail.gmail.com>
>Content-Type: text/plain; charset=US-ASCII
>
>On Wed, 2 Mar 2005 11:01:42 +0530, kiran.aral@wipro.com
><kiran.aral@wipro.com> wrote:
>> 
>> Hello All,
>> 
>> As Kumar mentioned, Block size of 8192 would definitely increase memory
>> requirements for decoder implementation. Thanks Kumar, for mentioning
>> this in this forum. I also emphasize the low memory requirements and
>> less complexity on the decoder side would increase Vorbis' presence
in
>> audio market especially in portable player market.
>> 
>> I also suggest Vorbis project to draft an amendment by removing 4096
and
>> 8192 block sizes for Vorbis implementation on embedded platforms
>> provided there are no definite advantages.
>
>If we did remove 8196 (and I'm not saying we would), we _certainly_
>wouldn't even consider removing 4096 - that's in wide use, and has
>been for some years. Removing it would break a lot of files that users
>are happily playing at the moment.
>

But I think, in stereo, if 4096 block size supportted, another 3K words(32
bits/word) for workbuffer
and another 2K words(32 bits/word or 16 bits/word) for window table, it is a not
acceptted in portable
audio player. then, I also suggest not supportting 4096 and 8192 block sizes.


>I don't think removing 8196 is really something we'd want to do
either
>- as a concession to limited-memory devices, the final format
>specification (as finalised when we did the libvorbis 1.0 release)
>removed several larger block sizes that had previously been permitted
>(I think these were 16k, 32k, and 64k).
>
>I don't think we want to retroactively change the vorbis format (for a
>future "vorbis 2", we'd certainly be willing to consider any
sort of
>changes, though).
>
>Mike
>

>> >
>> >If we did remove 8196 (and I'm not saying we would), we
_certainly_
>> >wouldn't even consider removing 4096 - that's in wide use,
and has
>> >been for some years. Removing it would break a lot of files that
users
>> >are happily playing at the moment.
>> >
>> 
>> But I think, in stereo, if 4096 block size supportted, another 3K
words(32 bits/word) for workbuffer
>> and another 1K words(32 bits/word or 16 bits/word) for window table, it
is a not acceptted in portable
>> audio player. then, I also suggest not supportting 4096 and 8192 block
sizes.
>
>As Monty and I said, block size 4096 is used by most encoders (though
>only at some bitrates) for cd-rate audio. So removing that is not
>acceptable for vorbis-compliant decoders.
>
>Monty noted that 8192 is only useful for high-sampling-rate audio
>(such as 96kHz material), and it's reasonable for a portable device to
>not support those files. So a portable could omit the 8192 size.
>
>We're thinking about defining a "portable profile" that limits
various
>aspects of the vorbis specification. That 8192 block size would be one
>of the things that wouldn't be required in such a profile, but 4096
>would still be required.
>
>Mike
Thank you and monty for your answers.
Though I still don't want to support these audio files with 4096 
block size, considering SRAM resource, but I am so glad to hear that 
a "portable profile" will be defined in future, and I also have some 
thinking on it:
	1, support of floor type0?  2, limitation of total codebooks size?
	3, limitation on ogg page size(considering CRC checksum)?
jim luo
thx.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face-3.gif
Type: image/gif
Size: 842 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20050304/b39bc0d3/face-3.gif

>> Thank you and monty for your answers.
>> Though I still don't want to support these audio files with 4096
>> block size, considering SRAM resource, but I am so glad to hear that
>> a "portable profile" will be defined in future, and I also
have some
>> thinking on it:
>>         1, support of floor type0?  2, limitation of total codebooks
size?
>>         3, limitation on ogg page size(considering CRC checksum)?
>> jim luo
>> thx.
>
>I suspect we'd drop floor 0 for a portable profile. Obviously, the
>codebook size would be limited (the details of that I haven't thought
>about, but it should be easy to define).
>Limiting the ogg page size I hadn't really thought about, that's
>probably a sensible thing to add.
>
>Mike
Thanks for your answer. I wish such portable profile coming out as soon as
possible.
 Jim