[Vorbis-dev] padding in comment header

[Ian Malone]

Ralph Giles wrote:
> On Fri, Feb 03, 2006 at 03:36:17PM +0000, Ian Malone wrote:
> 
> 
>>Having looked through the archives I've come to the conclusion that
>>to do padding for comments (in a file tagging context) the simplest
>>solution is to zero pad the comment header packet to fixed length[1]
>>and regenerate pages from #2 up to the first one containing the setup
>>header. Is this correct?
> 

> make small changes without rewriting the entire file. And if you're 
> going to do that the "round up to the nearest power of two" heuristic is 
> a fine one. (I'd suggest "over 1024 bytes and more than half padding" as
> a definition of "ridiculously sparse" btw.)
> 

A little hysteresis would be a good idea, I can probably come up with
a better strategy if I put some thought into it.

> Whether this is the simplest solution? I don't know. All our tools 
> embed exact-size comment header packets, and any tagging software
> has to handle the re-write case, so this is more of an optimization
> than a simplification. Is making retagging faster worth wasting a
> few hundred bytes per file? If I'm thinking of files on disk, I'd
> say yes. If I'm thinking of streaming (as people usually have been
> when developing vorbis) or files on disc, I'd say no.
> 

I was thinking of looking at patching vorbiscomment to handle non-
Vorbis I.  Since padding seems to be something people want (from
looking at Hydrogen Audio, not the most representative sample) it
seems worth considering it at the same time.  To be honest, to make
it even noticeably useful, oggenc needs an add padding option as
well (otherwise only people who re-tag large numbers of files twice
will see any benefit).  It's not something that worries me really.
If it is done it would probably be best as a non-default option for
people who care enough to look into it.

> The spec doesn't say anything about the padding either way, but it
> should be legal and I'm not aware of a tool that doesn't handle it
> properly. So if you want to do this, please go ahead.
> 
> As far as page regeneration, if you don't change the number of pages,
> regenerating just the pages that contain some fraction of the comment
> header works. If you have to change the number of pages, you have
> to update the page number (and crc) of every subsequent page in the
> stream.
> 
> Note that vorbiscomment repages everything. It started as laziness, but 
> turns out to be a helpful normalization tool too.
> 

Actually, that's what lead to the next question, I was trying to get
away without having to use the vorbiscomment repaging (repaginating?)
in my toy padder (when the number of pages in the header changes).

> 
>>Not very closely related: should doing ogg_stream_pagein followed
>>by while(ogg_stream_pageout()>0) on a stream work (I could check
>>the code, but I'm sure someone here will just know), or must page
>>in/out always be followed by the complimentary packet in/out?
> 
> 
> It *should* work, but I don't know. I wouldn't be too surprised if
> it buffered data forever, waiting for a corresponding packet_out, 
> but that would be a bug. What are you trying to do here?
> 

(as above) Push data pages into the stream, get them back out with the
correct page number (and hopefully correct granulepos as the contents
should be the same given that no fraction of the header packets goes
into the data pages).

I'm segfaulting, but since the toy padder is a messy cut and paste
piece of work it's more than likely a memory leak somewhere is
interfering with ogg stream internals.  If I get time I'll do a
clean test.

-- 
imalone