GSM <-> PCM converter

479 views
Skip to first unread message

Galian

unread,
May 22, 2007, 12:02:18 PM5/22/07
to
Hi all. I need some help with GSM-PCM converter implementation.
This is my code, all ACM functions return MMSYSERR_NOERROR, but data,
that I receive from destination buffer is wrong ( I hear in earphone
only comfort noise, and some sibilant ).It's application under Windows
Mobile 5.0. I don't know what's wrong. If some body can help me, it
will be excellent.
Thanks.

GSMConverter.h

typedef unsigned char u8; /* Exactly one byte (8 bits) */
typedef unsigned short u16; /* Exactly 2 bytes (16 bits) */
typedef unsigned long u32; /* Exactly 4 bytes (32 bits) */

class CGSMConverter
{
public:
enum EConvertDirection { PCM_TO_GSM, GSM_TO_PCM };
CGSMConverter( void );
virtual ~CGSMConverter( void );
AudioError InitConverter( EConvertDirection eDirection );
void TermConverter( void );

// Return number of bytes converted, stored in m_pDestBuffer
u32 Convert( const u8* pData, u32 iDataLength );

inline const u8* GetDestBuffer() { return m_pDestBuffer; }

protected:
HACMSTREAM m_hAcmStream;
WAVEFORMATEX m_PCMStruct;
GSM610WAVEFORMAT m_GSMStruct;
PWAVEFORMATEX m_pSrcFormat;
LPWAVEFORMATEX m_pDstFormat;

private:
u8* m_pSrcBuffer;
u8* m_pDestBuffer;
u32 m_iSrcBufferLength;
u32 m_iDestBufferLength;
};


GSMConverter.cpp

#define PREFERRED_FRAMES_PER_PACKET 4
#define PCM_FRAME_SIZE 320
#define GSM_DOUBLE_FRAME_SIZE 65

#include "StdAfx.h"
#include "GSMConverter.h"

CGSMConverter::CGSMConverter( void )
: m_hAcmStream( NULL )
, m_pSrcFormat( NULL )
, m_pDstFormat( NULL )
, m_pSrcBuffer( NULL )
, m_pDestBuffer( NULL )
, m_iSrcBufferLength( 0 )
, m_iDestBufferLength( 0 )
{
// PCM struct initialization

m_PCMStruct.wFormatTag = WAVE_FORMAT_PCM;
m_PCMStruct.nChannels = 1;
m_PCMStruct.nSamplesPerSec = 8000;
m_PCMStruct.nAvgBytesPerSec = 16000;
m_PCMStruct.nBlockAlign = 2;
m_PCMStruct.wBitsPerSample = 16;
m_PCMStruct.cbSize = 0;

// GSM struct initialization

//m_GSMStruct
m_GSMStruct.wfx.wFormatTag = WAVE_FORMAT_GSM610;
m_GSMStruct.wfx.nChannels = 1;
m_GSMStruct.wfx.nSamplesPerSec = 8000;
m_GSMStruct.wfx.nAvgBytesPerSec = 1625;
m_GSMStruct.wfx.nBlockAlign = 65;
m_GSMStruct.wfx.wBitsPerSample = 0;
m_GSMStruct.wfx.cbSize = 2;
m_GSMStruct.wSamplesPerBlock = 320;
}

CGSMConverter::~CGSMConverter( void )
{

}

AudioError CGSMConverter::InitConverter( EConvertDirection
eDirection )
{
AudioError iInitRes = AudioErrorNone;

if ( PCM_TO_GSM == eDirection )
{
m_iSrcBufferLength = PCM_FRAME_SIZE * PREFERRED_FRAMES_PER_PACKET;
m_iDestBufferLength = GSM_DOUBLE_FRAME_SIZE *
( PREFERRED_FRAMES_PER_PACKET / 2 );

m_pSrcFormat = &m_PCMStruct;
m_pDstFormat = reinterpret_cast< LPWAVEFORMATEX >( &m_GSMStruct );
}
else
{
m_iSrcBufferLength = GSM_DOUBLE_FRAME_SIZE *
( PREFERRED_FRAMES_PER_PACKET / 2 );
m_iDestBufferLength = PCM_FRAME_SIZE * PREFERRED_FRAMES_PER_PACKET;

m_pSrcFormat = reinterpret_cast< LPWAVEFORMATEX >( &m_GSMStruct );
m_pDstFormat = &m_PCMStruct;
}

// Allocating memory for destination and source buffers
m_pSrcBuffer = new u8[ m_iSrcBufferLength ];
m_pDestBuffer = new u8[ m_iDestBufferLength ];

DWORD dwOpenFlags = ACM_STREAMOPENF_NONREALTIME;

MMRESULT openStreamResult = acmStreamOpen(
&m_hAcmStream // stream handle
, NULL // handle to ACM driver
, m_pSrcFormat // source WAVEFORMATEX struct
, m_pDstFormat // destination WAVEFORMATEX struct
, NULL // filter
, NULL // callback
, NULL // instance data
, dwOpenFlags // open flags
);

if ( MMSYSERR_NOERROR != openStreamResult )
{
iInitRes = AudioErrorInitConverter;
}

return iInitRes;
}

u32 CGSMConverter::Convert( const u8* pData, u32 iDataLength )
{
u32 iConvertResult = 0;

DWORD dwConvertFlags = 0;

ACMSTREAMHEADER streamHeader;

memset( &streamHeader, 0, sizeof( ACMSTREAMHEADER ) );
streamHeader.cbStruct = sizeof( ACMSTREAMHEADER );
streamHeader.pbSrc = m_pSrcBuffer;
streamHeader.cbSrcLength = m_iSrcBufferLength;
streamHeader.cbSrcLengthUsed = iDataLength;
streamHeader.dwSrcUser = 0;
streamHeader.pbDst = m_pDestBuffer;
streamHeader.cbDstLength = m_iDestBufferLength;
streamHeader.cbDstLengthUsed = 0;
streamHeader.dwDstUser = 0;

MMRESULT streamPrepareHeader = acmStreamPrepareHeader( m_hAcmStream,
&streamHeader, 0 );

if ( MMSYSERR_NOERROR == streamPrepareHeader )
{
MMRESULT streamConvertRes = acmStreamConvert( m_hAcmStream,
&streamHeader, dwConvertFlags );

if ( MMSYSERR_NOERROR == streamConvertRes )
{
iConvertResult = streamHeader.cbDstLengthUsed;
}
}

if ( streamHeader.fdwStatus & ACMSTREAMHEADER_STATUSF_PREPARED )
{
MMRESULT streamUnprepareHeader =
acmStreamUnprepareHeader( m_hAcmStream, &streamHeader, 0 );

}

return iConvertResult;
}

void CGSMConverter::TermConverter( void )
{
// Releasing memory allocated for destination and source buffers
delete [] m_pSrcBuffer;
delete [] m_pDestBuffer;

// Closing stream
MMRESULT closeStreamResult = acmStreamClose( m_hAcmStream, 0 );
}

alang...@aol.com

unread,
May 23, 2007, 5:52:46 PM5/23/07
to
On May 22, 5:02?pm, Galian <galicia.developmentgr...@gmail.com> wrote:
> Hi all. I need some help with GSM-PCM converter implementation.
> This is my code, all ACM functions return MMSYSERR_NOERROR, but data,
> that I receive from destination buffer is wrong ( I hear in earphone
> only comfort noise, and some sibilant ).It's application under Windows
> Mobile 5.0. I don't know what's wrong. If some body can help me, it
> will be excellent.
<snip>

I don't do Windows Mobile or C but apart from thr buffer sizes it
looks OK to me. I presume that the conversion code is called multiple
times in a loop. As so there is no need to Prepare & UnPrepare the
header for each converted frame. Unles you are increasing the
specified memory you can use the same Prepared header throught.

Your buffer sizing appears correct, but while you've got the correct
relationship, the calculation appears "magical". Basically 320 samples
of PCM convert to 1 block of GSM. PCM (Mono 16 bits/sample) uses 2
bytes per block (sample). GSM uses 65 bytes / block. So 640 PCM bytes
convert to 65 bytes of GSM.

So the calculations are ...

GSMBytesPerBuffer = GSMBytesPerGSMBlock * GSMBlocksPerBuffer
(I thinkPreferredFramesPerPacket are GSMBlocksPerBuffer)

260 = 65 * 4

PCMBytesPerBuffer = PCMBytesPerPCMBlock * PCMBlocksPerGSMBlock *
GSMBlocksPerBuffer
(I think PCMBlocksPerGSMBlock are PCMSamplesPerGSMBlock)

2560 = 2 * 320 * 4

... or 130 and 1280 with only 2 GSMBlocksPerBuffer.

Alan Lloyd


Galian

unread,
May 24, 2007, 2:19:04 AM5/24/07
to

alang...@aol.com :

Hi Alan!
Thank you for your answer.

I already found an error, It was ( as usually ) small logical error,
which I doesn't seen.
About calculating buffer sizes:

if I right understand two GSM frames, haves a size 65 bytes ( 32,5
bytes - one GSM frame )
So, for 4 PCM frames buffer size = 320 * 4 = 1280 bytes
and for 4 GSM frames buffer size = 65 * ( 4 / 2 ) = 130 bytes
I thing you missed " / 2 " in my code for calculating GSM buffer size

Thank you again for focus attention.

alang...@aol.com

unread,
May 24, 2007, 3:56:15 AM5/24/07
to
On May 24, 7:19?am, Galian <galicia.developmentgr...@gmail.com> wrote:
<snip>

>
> if I right understand two GSM frames, haves a size 65 bytes ( 32,5
> bytes - one GSM frame )
> So, for 4 PCM frames buffer size = 320 * 4 = 1280 bytes
> and for 4 GSM frames buffer size = 65 * ( 4 / 2 ) = 130 bytes
> I thing you missed " / 2 " in my code for calculating GSM buffer size
>

My point was that you got the correct answer using the wrong
calculation. GSM has a block (frame) of 65 bytes and is only mono. You
would get the same sized GSM output whether your input of a constant
number of samples (ie same time of record) were stereo or mono PCM.

So your "double-frame" concept which implies a GSM block of 32.5 bytes
for mono is a fallacy. Your calculation should have used a multiple of
2 (for PCM bytes/block) when calculating the PCM buffer, not using a
false divisor of 2 on the GSM buffer calculation.

Is your ring finger shorter than your index finger ? <g>

Alan Lloyd

Galian

unread,
May 24, 2007, 6:08:58 AM5/24/07
to

> My point was that you got the correct answer using the wrong
> calculation. GSM has a block (frame) of 65 bytes and is only mono. You
> would get the same sized GSM output whether your input of a constant
> number of samples (ie same time of record) were stereo or mono PCM.
>
> So your "double-frame" concept which implies a GSM block of 32.5 bytes
> for mono is a fallacy. Your calculation should have used a multiple of
> 2 (for PCM bytes/block) when calculating the PCM buffer, not using a
> false divisor of 2 on the GSM buffer calculation.
>
> Is your ring finger shorter than your index finger ? <g>
>
> Alan Lloyd

Sorry Alan, but I still don't understand.
I have mono PCM, I want to convert it to mono GSM.
I thought, that 65 bytes it's size of two GSM frames, it's wrong?
One 320 PCM = One X size GSM frame, so what meaning of X?
Sorry Alan for dullness, I just study.
Thank you.

alang...@aol.com

unread,
May 24, 2007, 8:43:25 AM5/24/07
to
On May 24, 11:08?am, Galian <galicia.developmentgr...@gmail.com>
wrote:
<snip>

> Sorry Alan, but I still don't understand.
> I have mono PCM, I want to convert it to mono GSM.
> I thought, that 65 bytes it's size of two GSM frames, it's wrong?
> One 320 PCM = One X size GSM frame, so what meaning of X?
> Sorry Alan for dullness, I just study.

GSM is always & only mono. A block (maybe the same as your frame) is
the smallest chunk of the format.

For PCM a block is one sample and may be 8 or 16 bits and may be mono
(one channel) or stereo (two channels), or even more in "surround
sound". So a PCM block is ...

BitsPerSample / 8 * ChannelCount bytes, and is 4 BytesPerBlock for 16-
bit Stereo, 2 BytesPerBlock for 16-bit Mono

For GSM each block is 65 bytes and always mono. Each block contains
320 samples of PCM. So a GSM block is always 65 bytes of GSM data
derived from 320 blocks of PCM data.

So it holds 320 * PCMBytesPerBlock of PCM data. Which for 16-bit mono
PCM will be 640 bytes.

If you deal in two GSM blocks per buffer that means that 1280 buffer
bytes of PCM 16-bit Mono would fit into 130 bytes of GSM buffer.

It is inaccurate to talk about a GSM_DOUBLE_FRAME, there is only a
GSM_BLOCK of 65 bytes. Dividing the PREFERRED_FRAMES_PER_PACKET by 2
instead of including the PCM BytesPerBlock in the PCM buffer
calculation, gets the right answer using the wrong method.

There is no concept of "frames" in either PCM or GSM, only blocks. One
could, I suppose, talk about frames in GSM because each block (could
be a frame) holds a multiplicity of PCM blocks. But it is not a
conventionally descriptive term.

If you put the correct intermediate elements in your calculation they
work out to be in the correct units (ie bytes/buffer). the terms you
used do not work out to that correct unit.

Using correct terminology and clear coding & calculation does not, I
suppose, matter much as of now. But when you have learnt more about
processes, and six-months later you look at your past code, you will
say "What on earth was I doing in that piece of code". That's the
result of writng code which has poor clarity.

Alan Lloyd

Chris P.

unread,
May 24, 2007, 3:06:27 PM5/24/07
to
On 24 May 2007 05:43:25 -0700, alang...@aol.com wrote:

> For GSM each block is 65 bytes and always mono. Each block contains
> 320 samples of PCM. So a GSM block is always 65 bytes of GSM data
> derived from 320 blocks of PCM data.

Actually Galian is correct about the GSM frame size. Each GSM frame
represents 160 PCM samples (20ms) at a frame rate of 50 frames a second.
The compressed data is packed into 260 bits, or 32.5 bytes. In PC land we
usually work with double frames as the .5 is tough to manage.

--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]

Mark Salsbery

unread,
May 25, 2007, 5:42:01 PM5/25/07
to
That may be true of GSM in general, but the GSM ACM codec included with the
MS operating systems has a block size of 65 bytes which is always 320 samples.
In other words, ACM doesn't let us work with 260-bit blocks.

I'm probably just repeating what you were stating - interesting to me
nonetheless, thanks!

Mark

Chris P.

unread,
May 25, 2007, 6:09:29 PM5/25/07
to
On Fri, 25 May 2007 14:42:01 -0700, Mark Salsbery wrote:

> That may be true of GSM in general, but the GSM ACM codec included with the
> MS operating systems has a block size of 65 bytes which is always 320 samples.
> In other words, ACM doesn't let us work with 260-bit blocks.
>
> I'm probably just repeating what you were stating - interesting to me
> nonetheless, thanks!

Exactly. Hence my statement "In PC land we usually work with double frames
as the .5 is tough to manage.", a double frame is 320 samples.

alang...@aol.com

unread,
May 26, 2007, 1:56:07 AM5/26/07
to
On May 25, 11:09�pm, "Chris P." <m...@chrisnet.net> wrote:
<snip>

> Exactly.  Hence my statement "In PC land we usually work with double frames
> as the .5 is tough to manage.", a double frame is 320 samples.

I didn't know that, and it confirms my uncertainty of the definition
of "frames".

A "block" I can understand as the smallest chunk of data in the
subject format.

The logical definition of "frame" would be the chunk of many blocks a
particular application is using.

But is that so, and how does it fit with a situation (as in PC GSM)
where the smallest chunk of data one _can_ use consists of two-blocks.
And in domestic interlaced TV a frame is half a block of visual data.

And if "block" & "frame" is interchangeable, why have the two.

Alan Lloyd

Chris P.

unread,
May 26, 2007, 10:31:06 AM5/26/07
to
On 25 May 2007 22:56:07 -0700, alang...@aol.com wrote:

> I didn't know that, and it confirms my uncertainty of the definition
> of "frames".
>
> A "block" I can understand as the smallest chunk of data in the
> subject format.
>
> The logical definition of "frame" would be the chunk of many blocks a
> particular application is using.
>
> But is that so, and how does it fit with a situation (as in PC GSM)
> where the smallest chunk of data one _can_ use consists of two-blocks.
> And in domestic interlaced TV a frame is half a block of visual data.
>
> And if "block" & "frame" is interchangeable, why have the two.

Frame refers to the transmission size where as block refers to the smallest
representable data size. So for the PC GSM one block = 2 frames.

For interlaced video it gets a little confusing as a frame is 2 blocks,
i.e. 2 fields.

Galian

unread,
May 30, 2007, 3:22:07 AM5/30/07
to

Thanks you all guys for answers. Maybe you know, some documents, some
articles, books, where can I read about frames, samples, frequencies
and so on. Thank you all. Thanks to you, the same as me can be an
apprentice to a professionals as you.

P.S. Sorry for my bad English.

Emily Henry

unread,
May 6, 2012, 9:23:45 PM5/6/12
to
Bigasoft Audio Converter is just the ideal PCM Converter which can fast convert PCM to WAV, MP3, AIFF, WMA, AAC, AC3, M4A, FLAC and etc with high audio quality and smaller file size. It supports converting all kinds of PCM files to any kind of audio format. This powerful PCM Converter also enables to convert between almost all kinds of audio formats including OGG, AIFF, ALAC, FLAC, CAF, APE, CUE, QCP, AMR, AWB, MP3, WMA, M4A, AAC, AC3, and WAV and so on. It even supports to convert from video formats including AVI, WMV, MKV, MOV, MP4, VOB, H.264, 3GP, FLV, MTS to any kind of audio format.

The following will describe a step by step guide on how to convert PCM to any other audio format with the help of the professional PCM Converter - Bigasoft Audio Converter at http://www.bigasoft.com/articles/how-to-convert-pcm-audio.html



> On Tuesday, May 22, 2007 12:02 PM Galian wrote:

> Hi all. I need some help with GSM-PCM converter implementation.
> This is my code, all ACM functions return MMSYSERR_NOERROR, but data,
> that I receive from destination buffer is wrong ( I hear in earphone
> only comfort noise, and some sibilant ).It's application under Windows
> Mobile 5.0. I don't know what's wrong. If some body can help me, it
> will be excellent.
>>> On Thursday, May 24, 2007 2:19 AM Galian wrote:

>>> alang...@aol.com :
>>>
>>> Hi Alan!
>>> Thank you for your answer.
>>>
>>> I already found an error, It was ( as usually ) small logical error,
>>> which I doesn't seen.
>>> About calculating buffer sizes:
>>>
>>> if I right understand two GSM frames, haves a size 65 bytes ( 32,5
>>> bytes - one GSM frame )
>>> So, for 4 PCM frames buffer size = 320 * 4 = 1280 bytes
>>> and for 4 GSM frames buffer size = 65 * ( 4 / 2 ) = 130 bytes
>>> I thing you missed " / 2 " in my code for calculating GSM buffer size
>>>
>>> Thank you again for focus attention.


>>>> On Thursday, May 24, 2007 3:56 AM alanglloy wrote:

>>>> On May 24, 7:19?am, Galian <galicia.developmentgr...@gmail.com> wrote:
>>>> <snip>
>>>>
>>>> My point was that you got the correct answer using the wrong
>>>> calculation. GSM has a block (frame) of 65 bytes and is only mono. You
>>>> would get the same sized GSM output whether your input of a constant
>>>> number of samples (ie same time of record) were stereo or mono PCM.
>>>>
>>>> So your "double-frame" concept which implies a GSM block of 32.5 bytes
>>>> for mono is a fallacy. Your calculation should have used a multiple of
>>>> 2 (for PCM bytes/block) when calculating the PCM buffer, not using a
>>>> false divisor of 2 on the GSM buffer calculation.
>>>>
>>>> Is your ring finger shorter than your index finger ? <g>
>>>>
>>>> Alan Lloyd


>>>>> On Thursday, May 24, 2007 6:08 AM Galian wrote:

>>>>> Sorry Alan, but I still don't understand.
>>>>> I have mono PCM, I want to convert it to mono GSM.
>>>>> I thought, that 65 bytes it's size of two GSM frames, it's wrong?
>>>>> One 320 PCM = One X size GSM frame, so what meaning of X?
>>>>> Sorry Alan for dullness, I just study.
>>>>> Thank you.


>>>>>> On Thursday, May 24, 2007 8:43 AM alanglloy wrote:

>>>>>> On May 24, 11:08?am, Galian <galicia.developmentgr...@gmail.com>
>>>>>> wrote:
>>>>>> <snip>
>>>>>>
>>>>>> GSM is always & only mono. A block (maybe the same as your frame) is
>>>>>> the smallest chunk of the format.
>>>>>>
>>>>>> For PCM a block is one sample and may be 8 or 16 bits and may be mono
>>>>>> (one channel) or stereo (two channels), or even more in "surround
>>>>>> sound". So a PCM block is ...
>>>>>>
>>>>>> BitsPerSample / 8 * ChannelCount bytes, and is 4 BytesPerBlock for 16-
>>>>>> bit Stereo, 2 BytesPerBlock for 16-bit Mono
>>>>>>
>>>>>> For GSM each block is 65 bytes and always mono. Each block contains
>>>>>> 320 samples of PCM. So a GSM block is always 65 bytes of GSM data
>>>>>> derived from 320 blocks of PCM data.
>>>>>>
>>>>>> So it holds 320 * PCMBytesPerBlock of PCM data. Which for 16-bit mono
>>>>>> PCM will be 640 bytes.
>>>>>>
>>>>>> If you deal in two GSM blocks per buffer that means that 1280 buffer
>>>>>> bytes of PCM 16-bit Mono would fit into 130 bytes of GSM buffer.
>>>>>>
>>>>>> It is inaccurate to talk about a GSM_DOUBLE_FRAME, there is only a
>>>>>> GSM_BLOCK of 65 bytes. Dividing the PREFERRED_FRAMES_PER_PACKET by 2
>>>>>> instead of including the PCM BytesPerBlock in the PCM buffer
>>>>>> calculation, gets the right answer using the wrong method.
>>>>>>
>>>>>> There is no concept of "frames" in either PCM or GSM, only blocks. One
>>>>>> could, I suppose, talk about frames in GSM because each block (could
>>>>>> be a frame) holds a multiplicity of PCM blocks. But it is not a
>>>>>> conventionally descriptive term.
>>>>>>
>>>>>> If you put the correct intermediate elements in your calculation they
>>>>>> work out to be in the correct units (ie bytes/buffer). the terms you
>>>>>> used do not work out to that correct unit.
>>>>>>
>>>>>> Using correct terminology and clear coding & calculation does not, I
>>>>>> suppose, matter much as of now. But when you have learnt more about
>>>>>> processes, and six-months later you look at your past code, you will
>>>>>> say "What on earth was I doing in that piece of code". That's the
>>>>>> result of writng code which has poor clarity.
>>>>>>
>>>>>> Alan Lloyd


>>>>>>> On Thursday, May 24, 2007 3:06 PM Chris P. wrote:

>>>>>>> On 24 May 2007 05:43:25 -0700, alang...@aol.com wrote:
>>>>>>>
>>>>>>>
>>>>>>> Actually Galian is correct about the GSM frame size. Each GSM frame
>>>>>>> represents 160 PCM samples (20ms) at a frame rate of 50 frames a second.
>>>>>>> The compressed data is packed into 260 bits, or 32.5 bytes. In PC land we
>>>>>>> usually work with double frames as the .5 is tough to manage.
>>>>>>>
>>>>>>> --
>>>>>>> http://www.chrisnet.net/code.htm
>>>>>>> [MS MVP for DirectShow / MediaFoundation]


>>>>>>>> On Friday, May 25, 2007 5:42 PM MarkSalsber wrote:

>>>>>>>> That may be true of GSM in general, but the GSM ACM codec included with the
>>>>>>>> MS operating systems has a block size of 65 bytes which is always 320 samples.
>>>>>>>> In other words, ACM doesn't let us work with 260-bit blocks.
>>>>>>>>
>>>>>>>> I'm probably just repeating what you were stating - interesting to me
>>>>>>>> nonetheless, thanks!
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> "Chris P." wrote:


>>>>>>>>> On Friday, May 25, 2007 6:09 PM Chris P. wrote:

>>>>>>>>> On Fri, 25 May 2007 14:42:01 -0700, Mark Salsbery wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Exactly. Hence my statement "In PC land we usually work with double frames
>>>>>>>>> as the .5 is tough to manage.", a double frame is 320 samples.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> http://www.chrisnet.net/code.htm
>>>>>>>>> [MS MVP for DirectShow / MediaFoundation]


>>>>>>>>>> On Saturday, May 26, 2007 1:56 AM alanglloy wrote:

>>>>>>>>>> On May 25, 11:09=EF=BF=BDpm, "Chris P." <m...@chrisnet.net> wrote:
>>>>>>>>>> <snip>
>>>>>>>>>> ames
>>>>>>>>>>
>>>>>>>>>> I didn't know that, and it confirms my uncertainty of the definition
>>>>>>>>>> of "frames".
>>>>>>>>>>
>>>>>>>>>> A "block" I can understand as the smallest chunk of data in the
>>>>>>>>>> subject format.
>>>>>>>>>>
>>>>>>>>>> The logical definition of "frame" would be the chunk of many blocks a
>>>>>>>>>> particular application is using.
>>>>>>>>>>
>>>>>>>>>> But is that so, and how does it fit with a situation (as in PC GSM)
>>>>>>>>>> where the smallest chunk of data one _can_ use consists of two-blocks.
>>>>>>>>>> And in domestic interlaced TV a frame is half a block of visual data.
>>>>>>>>>>
>>>>>>>>>> And if "block" & "frame" is interchangeable, why have the two.
>>>>>>>>>>
>>>>>>>>>> Alan Lloyd
Reply all
Reply to author
Forward
0 new messages