[vorbis-dev] frame_info_add

[macik.sk at post.sk]

> What you\'re really asking about is a logical-stream-level initial and ending
> offset value, not a frame-level value, I think.  Basically, \'skip the first x
> samples, ignore the last y\' in a bitstream section correct?

Yes. Logical-stream-level is enough. At frame-level it\'s wasting space, I agree.

> (What you may not be aware of is that two Vorbis files concatenated is a new, 
> valid vorbis file, supported by the spec.  The only restriction is that any 
> one \'logical\' bitstream within the \'physical\' bitstream must have a unique 
> serial number.  The libs already supports this).

It\'s fine but I would like to be possible something like this:

Block size=512 samples.
We have encoded Vorbis file. We want to cut PCM samples from 200 (middle of first frame) to 700 (middle of second frame) and store them in another Vorbis file. Default solution is: 

1) Decode first two frames => we have 1024 raw PCM
2) Cut from 200 to 700 => we have 500 raw PCM
3) Encode 500 PCM => we have one frame of encoded PCM

With offsets we can simple do copy first two frames and set initial and ending offset.

> So you want an adjustable begin/end offset... which wouldn\'t be too difficult.
> We can put it on the first/last pages only; this would require regenerating the
> page structure for deep edits, but this is designed to be easy to do and it
> doesn\'t require going to PCM.

Yes, accurately.

> Here\'s an additional question: 
> 
> Are you aware of systems/formats that currently require sample-level editing
> granularity?  I stopped to think long enough before replying to see that it
> would be of value (and indeed, you *don\'t* want to go back to PCM and reencode
> a lossy transport medium like Vorbis).  I\'m just wondering what your practical
> examples are right now.

I thought about audio sequencers like CuBase or (I hope in future) Brahms, Cool Edit Pro, Adobe Premiere... In these apps I can cut/copy/paste PCM at any position (maybe not sample-granularity, but at least not depending on audio frame size but SMPTE, MTC, internal something...). We should be versatile and not limiting factor.

> > I know it may cause inner fragmentation but advantages are promising (audio HD recording, video post production - all without recompressing)...
> 
> Actually, it doesn\'t.  It requires a new feature at the framing level (thank 
> god I wrote unit tests), but that new feature isn\'t particularly intrusive to 
> the overall fabric.

I thought about unused samples at beginning and ending  (see my example above - we have two frames but only 500 valid samples).

macik
                

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/