Just a random comment:
We need to convert all timestamp and size fields to 64-bit numbers. A
32-bit numBytes field doesn't get you very far with 8-channel, 96 kHz,
24-bit audio.
There is a proposal within MS for a RIFF64 chunk that would solve this (I
believe), with the obvious negative implication that yesterday's SW would
not understand that chunk. I'll see if I can find the proposal and send it
around.
-Martin
-----Original Message-----
From: bakker35 at euronet.NL [mailto:bakker35 at euronet.NL]
Sent: Tuesday, October 27, 1998 1:05 PM
To: Multiple recipients of list
Subject: Re: RFC - PEAK chunk
>I think that we could make a region chunk which was a wrapper for two
marker
>chunks and a peak chunk. So:
>
>typedef struct
>{
> MarkerChunk start;
> MarkerChunk end;
> PeakChunk peak;
>} Region;
>
> Non-float types could simply ignore the peak chunk. And this uses
the
>existing Marker specification.
A region would require a time stamp (or more than one) that indictates at
which time it was recorded, or which time it is placed in an editing
session.
If this region struct is supposed to become a chunk there will be two
sorts of marker chunk, those as they are now in the spec, and those
INSIDE a region chunk.
Alternative proposal:
typedef struct
{
OSType chunkType; // would be something like 'RLst'
long size;
long id[]; // list of id's of region chunks
};
typedef struct
{
OSType chunkType; // would be something like 'Regn'
long size;
long startMarkerID; // Refers to marker in regular marker chunk
long stopMarkerID; // Refers to marker in regular marker chunk
long peakID; // Refers to peak chunk, so that could do
with an ID no.
long timeStamp[]; // List of time stamps
};
The region list chunk can be used for playlists.
Peter Bakker
Audio Ease