Hi On Tue, Feb 21, 2006 at 07:26:07PM -0500, Rich Felker wrote: [...]
+ }else if (value==-3){ + type= "signed integer" + value s + }else if (value<-3){ + type= "rational" + value.den= -value-2 + value.num s
what advantage is there in the seperate "signed integer"?
I think the idea was that the program would know how to interpret it and display it even if it wasn't aware of the field's contents.
ok
+chapter_start + s= chapter_start % stream_count + timestamp= chapter_start / stream_count + timestamp of start of chapter in timebase of stream 's'. + Positive chapter_id's MUST be in sequential order.
IMHO chapter_start should be in the timebase of stream s if the info packet applies just to that stream
Is there a reasonable justification for chapters that apply to just one stream?
no, probably not "chapters" but chapters are the only way to specifiy start/stop times so if we want to allow describing a start/stop/stream ...
- "TotalTime" - total length of the stream in msecs
hmmmmm, global info packets dont have chapter_len, index is optional and you remove this umm ...
I thought it was our intent that index would not be "optional". IIRC I suggested defining in the spec a 'NUT stream authored for permenant storage' or something similar, and requiring such a stream to conform to several conditions such as: repeated headers, index present, ...
The idea is that a partially written, truncated, streamed, etc. NUT file would not be a a "NUT stream authored for permenant storage" and would not be subject to these requirements, but NUTlint would check these things and indicate to the user that the file is not conformant to the more restrictive requirements.
BTW in the case of a truncated file where the index is lost, knowing TotalTime is not useful anyway since it will be wrong.
and the chapter lengthes? its a PITA to go and read the index to find the last chapter length [...] -- Michael