Hi, I have this idea: It can be useful to have for each frame two variables stored in bitstream that will hold information about starting and ending position of \"valid\" samples in the frame. With these additional information it will be possible to do simple editing (like cutting or concatenating two streams) without decompressing/recompressing at sample-granularity. Simple example (size of frame==10 samples): | frame1 | frame2 | frame3 | frame4 | | | | 0000000000111111111122222222223333333333 : sample count 0123456789012345678901234567890123456789 : sample count | | | | A 0,9 B 0,9 C 0,9 D 0,9 A,B,C,D : compressed frames numbers 0,9: start and end position of valid pcm samples (new variables I\'m talking about). for example we need to cut samples 15 to 32. New bitstream can look like: A 0,9 B 0,5 D 2,9 or A 0,9 B 0,5 C 0,-1 D 2,9 Decoder decodes whole frame but should be able to write out only valid data == 22 samples. I know it may cause inner fragmentation but advantages are promising (audio HD recording, video post production - all without recompressing)... PS:Maybe I\'m missing something, I looked at sources only yeasty. PS2: All of this can be applied at application-side too so it is only proposition. macik --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> It can be useful to have for each frame two variables stored in bitstream that will hold information about starting and ending position of \"valid\" samples in the frame. > > With these additional information it will be possible to do simple editing (like cutting or concatenating two streams) without decompressing/recompressing at sample-granularity.(after cutting the below) 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? (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). 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. 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 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.> PS:Maybe I\'m missing something, I looked at sources only yeasty. > PS2: All of this can be applied at application-side too so it is only proposition.If we intended it to be a widely supported feature, it should be specced. Monty --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> 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/