1. 音频简介
经常见到这样的描述: 44100HZ 16bit stereo 或者 22050HZ 8bit mono 等等.
44100HZ 16bit stereo: 每秒钟有 44100 次采样, 采样数据用 16 位(2字节)记录, 双声道(立体声);
22050HZ 8bit mono: 每秒钟有 22050 次采样, 采样数据用 8 位(1字节)记录, 单声道;
当然也可以有 16bit 的单声道或 8bit 的立体声, 等等。
采样率是指：声音信号在“模→数”转换过程中单位时间内采样的次数。采样值是指每一次采样周期内声音模拟信号的积分值。
对于单声道声音文件，采样数据为八位的短整数（short int 00H-FFH）；
而对于双声道立体声声音文件，每次采样数据为一个16位的整数（int），高八位(左声道)和低八位(右声道)分别代表两个声道。
人对频率的识别范围是 20HZ - 20000HZ, 如果每秒钟能对声音做 20000 个采样, 回放时就足可以满足人耳的需求. 所以 22050 的采样频率是常用的, 44100已是CD音质, 超过48000的采样对人耳已经没有意义。这和电影的每秒 24 帧图片的道理差不多。
每个采样数据记录的是振幅, 采样精度取决于储存空间的大小:
1 字节(也就是8bit) 只能记录 256 个数, 也就是只能将振幅划分成 256 个等级;
2 字节(也就是16bit) 可以细到 65536 个数, 这已是 CD 标准了;
4 字节(也就是32bit) 能把振幅细分到 4294967296 个等级, 实在是没必要了.
如果是双声道(stereo), 采样就是双份的, 文件也差不多要大一倍.
这样我们就可以根据一个 wav 文件的大小、采样频率和采样大小估算出一个 wav 文件的播放长度。
譬如 "Windows XP 启动.wav" 的文件长度是 424,644 字节, 它是 "22050HZ / 16bit / 立体声" 格式(这可以从其 "属性->摘要" 里看到),
那么它的每秒的传输速率(位速, 也叫比特率、取样率)是 22050*16*2 = 705600(bit/s), 换算成字节单位就是 705600/8 = 88200(字节/秒),
播放时间：424644(总字节数) / 88200(每秒字节数) ≈ 4.8145578(秒)。
但是这还不够精确, 包装标准的 PCM 格式的 WAVE 文件(*.wav)中至少带有 42 个字节的头信息, 在计算播放时间时应该将其去掉,
所以就有：(424644-42) / (22050*16*2/8) ≈ 4.8140816(秒). 这样就比较精确了.
关于声音文件还有一个概念: "位速", 也有叫做比特率、取样率, 譬如上面文件的位速是 705.6kbps 或 705600bps, 其中的 b 是 bit, ps 是每秒的意思;
压缩的音频文件常常用位速来表示, 譬如达到 CD 音质的 MP3 是: 128kbps / 44100HZ.
2. wave文件格式
2.1 概述
WAVE文件是计算机领域最常用的数字化声音文件格式之一，它是微软专门为Windows系统定义的波形文件格式（Waveform Audio），由于其扩展名为"*.wav"。
WAVE是录音时用的标准的WINDOWS文件格式，文件的扩展名为“WAV”，数据本身的格式为PCM或压缩型。
WAV文件格式是一种由微软和IBM联合开发的用于音频数字存储的标准，它采用RIFF文件格式结构，非常接近于AIFF和IFF格式。符合 PIFF Resource Interchange File Format规范。所有的WAV都有一个文件头，这个文件头音频流的编码参数。
WAV对音频流的编码没有硬性规定，除了PCM之外，还有几乎所有支持ACM规范的编码都可以为WAV的音频流进行编码。
多媒体应用中使用了多种数据，包括位图、音频数据、视频数据以及外围设备控制信息等。RIFF为存储这些类型的数据提供了一种方法，RIFF文件所包含的数据类型由该文件的扩展名来标识，能以RIFF文件存储的数据包括：
音频视频交错格式数据(.AVI) 、波形格式数据(.WAV) 、位图格式数据(.RDI) 、MIDI格式数据(.RMI) 、调色板格式(.PAL) 、多媒体电影(.RMN) 、动画光标(.ANI) 、其它RIFF文件(.BND)。
wave文件有很多不同的压缩格式，所以，正确而详细地了解各种WAVE文件的内部结构是成功完成压缩和解压缩的基础，也是生成特有音频压缩格式文件的前提。
最基本的WAVE文件是PCM（脉冲编码调制）格式的，这种文件直接存储采样的声音数据没有经过任何的压缩，是声卡直接支持的数据格式，要让声卡正确播放其它被压缩的声音数据，就应该先把压缩的数据解压缩成PCM格式，然后再让声卡来播放。
2.2 Wave文件的内部结构
注：由于WAV格式源自Windows/Intel环境，因而采用Little-Endian字节顺序进行存储。
WAVE文件是以RIFF(Resource Interchange File Format, "资源交互文件格式")格式来组织内部结构的。
RIFF文件结构可以看作是树状结构，其基本构成是称为"块"（Chunk）的单元，最顶端是一个“RIFF”块，下面的每个块有“类型块标识(可选)”、“标志符”、“数据大小”及“数据”等项所组成。块的结构如表1所示：
| 名称 | Size | 备注 |
| 块标志符 | 4 | ４个小写字符(如 "fmt ", "fact", "data" 等) |
| 数据大小 | 4 | DWORD类型,表示后接数据的大小(N Bytes) |
| 数据 | N | 本块中正式数据部分 |
表１：基本chunk的内部结构
上面说到的“类型块标识”只在部分chunk中用到，如 "WAVE" chunk中，这时表示下面嵌套有别的chunk。
当使用了 "类型块标识" 时，该chunk就没有别的项（如块标志符，数据大小等），它只作为文件读取时的一个标识。先找到这个“类型块标识”，再以它为起点读取它下面嵌套的其它chunk。
每个文件最前端写入的是RIFF块，每个文件只有一个RIFF块。从 Wave文件格式详细说明 中可以看到这一点。
非PCM格式的文件会至少多加入一个 "fact" 块，它用来记录数据(注意是数据而不是文件)解压缩后的大小。这个 "fact" 块一般加在 "data" 块的前面。
WAVE文件是由若干个Chunk组成的。按照在文件中的出现位置包括：RIFF WAVE Chunk, Format Chunk, Fact Chunk(可选), Data Chunk。具体见下图：
-------------------------------------------
| RIFF WAVE Chunk |
| ID = "RIFF" |
| RiffType = "WAVE" |
-------------------------------------------
| Format Chunk |
| ID = "fmt " |
-------------------------------------------
| Fact Chunk(optional) |
| ID = "fact" |
-------------------------------------------
| Data Chunk |
| ID = "data" |
-------------------------------------------
图 Wav格式包含Chunk示例
Fact Chunk
=======================================
| |所占字节数| 具体内容 |
=======================================
| ID | 4Bytes | "fact" |
---------------------------------------
| Size | 4Bytes | 4 |
---------------------------------------
| data | 4Bytes |解压后的音频数据的大小(B)|
---------------------------------------
图 Fact Chunk
2.3 Wave文件格式详细说明
别名 字节数 类型 注释
ckid 4 char "RIFF" 标志, 大写
cksize 4 int32 文件长度。这个长度不包括"RIFF"标志 和
文件长度 本身所占字节, 下面的
子块大小也是这样。
fcc type 4 char "WAVE" 类型块标识, 大写。
ckid 4 char 表示"fmt" chunk的开始。此块中包括文
件内部格式信息。小写, 最后一个
字符是空格。
cksize 4 int32 文件内部格式信息数据的大小。
FormatTag 2 int16 音频数据的编码方式。1 表示是 PCM 编码
Channels 2 int16 声道数，单声道为1，双声道为2
SamplesPerSec 4 int32 采样率(每秒样本数), 比如 44100 等
BytesPerSec 4 int32 音频数据传送速率, 单位是字节。其值为
采样率×每次采样大小。播放软件
利用此值可以估计缓冲区的大小。
BlockAlign 2 int16 每次采样的大小 = 采样精度*声道数/8(单
位是字节); 这也是字节对齐的最
小单位, 譬如 16bit 立体声在这
里的值是 4 字节。播放软件需要
一次处理多个该值大小的字节数
据，以便将其值用于缓冲区的调整。
BitsPerSample 2 int16 每个声道的采样精度; 譬如 16bit 在这
里的值就是16。如果有多个声道，则
每个声道的采样精度大小都一样的。
[cbsize] 2 int16 [可选]附加数据的大小。
[...] x
[ckid] 4 char "fact".
ckid 4 char 表示 "data" chunk的开始。此块中包含
音频数据。小写。
cksize 4 int32 音频数据的长度
...... 文件声音信息数据(真正声音存储部分)
[......] 其它 chunk
2.4 Windows平台上WAVEFORMAT结构的认识
PCM和非PCM的主要区别是声音数据的组织不同，这些区别可以通过两者的WAVEFORMAT结构来区分。
下面以PCM和IMA-ADPCM来进行对比。
WAVE的基本结构 WAVEFORMATEX 结构定义如下：
1
typedef
struct
2
{
3
WORD wFormatag;
//
编码格式，包括WAVE_FORMAT_PCM，WAVEFORMAT_ADPCM等
4
WORD nChannls;
//
声道数，单声道为1，双声道为2;
5
6
DWORD nSamplesPerSec;
//
采样频率；
7
8
DWORD nAvgBytesperSec；
//
每秒的数据量；
9
10
WORD nBlockAlign;
//
块对齐；
11
12
WORD wBitsPerSample;
//
WAVE文件的采样大小；
13
14
WORD cbSize;
//
The count in bytes of the size of extra
15
//
information(after cbSize). PCM中忽略此值
16
} WAVEFORMATEX;
IMAADPCMWAVEFORMAT结构定义如下：
1
Typedef
struct
2
{
3
WAVEFORMATEX wfmt;
4
5
WORD nSamplesPerBlock;
6
7
} IMAADPCMWAVEFORMAT;
IMA-ADPCM中的的wfmt->cbsize不能忽略，一般取值为2，表示此类型的WAVEFORMAT比一般的WAVEFORMAT多出2个字节。这两个字符也就是nSamplesPerBlock。
"fact" chunk的内部组织
在非PCM格式的文件中,一般会在WAVEFORMAT结构后面加入一个 "fact" chunk, 结构如下：
view source print ?
| |
|
| |
|
| |
|
| |
|
| |
datafactsize是这个chunk中最重要的数据，如果这是某种压缩格式的声音文件，那么从这里就可以知道他解压缩后的大小。对于解压时的计算会有很大的好处！
2.5 "data" chunk的内部组织
从 "data" chunk的第9个字节开始，存储的就是声音信息的数据了，(前八个字节存储的是标志符 "data" 和后接数据大小size(DWORD)。这些数据可以是压缩的，也可以是没有压缩的。
3. PCM数据格式
PCM(Pulse Code Modulation)也被称为 脉码编码调制。PCM中的声音数据没有被压缩，如果是单声道的文件，采样数据按时间的先后顺序依次存入。(它的基本组织单位是BYTE(8bit)或WORD(16bit))
一般情况下，一帧PCM是由2048次采样组成的( 参考 http://discussion.forum.nokia.com/forum/showthread.php?129458-请问PCM格式的音频流，每次读入或输出的块的大小是必须固定为4096B么&s=e79e9dd1707157281e3725a163844c49 )。
Wave文件的格式非常混乱。如果把wave文件的格式比作盆汤，毫无疑问有太多的厨师在完全未经协调的情况下，向这道汤里添加了太多的佐料。Wave文 件的格式规范中，有太多相互独立而且缺乏协调的组织向其中增加内容。结果是wave文件中有很多chunk是在重复别的chunk中的数据，而且通常是用 一种完全不同的方式。下面的讲解中我们尽量把注意力集中于wave文件中那些最经常出现的chunk上。
____________________________
| RIFF WAVE Chunk |
| groupID = 'RIFF' |
| riffType = 'WAVE' |
| __________________ |
| | Format Chunk | |
| | ckID = 'fmt ' | |
| |__________________| |
| __________________ |
| | Sound Data Chunk | |
| | ckID = 'data' | |
| |__________________| |
|__________________________|
采样点和采样帧
解释一个Wave文件内容的过程很大部分围绕在采样点和采样帧这两个概念上。一个采样点是代表了给定声音在给定的时间点上的一个样本值。如果我们假设才用 的是PCM格式的wave文件，并且样点精度大于8bit，每一个采样点被保存为一个占用9-32bit的2的补码表示的数值。样点精度值保存在 Format chunk中的wBitsPerSample属性中。例如一个16bit波形中的一个采样点是一个线性的16bit有符号整数，取值范围- 32768～32767.但是8bit的波形文件中，每一个样本点是一个线性的无符号数，范围0～255。上述带符号和无符号表示方法的差异，又是微软员 工的杰作。
绝大多数cpu的读写指令都是真对8bit的“字节”的，如果一个波形文件的采样点精度不是8的整数倍，它必须被凑到最接近的8的整数倍。1－ 8bits/sample的波形文件用8bit保存一个样本，9-16bits/sample的波形文件用16bit保存一个样本……依此类推。
此外，数据比特是左对齐的，多余的填充bit都被设置为0。例如一个12bit的采样点，在wave文件中占用16bits，所以这两个字节的4－15号bit是数据，0－3号bit是填充的0。下图就是一个占据12bit的样点101000010111在内存中的情况：
| 1 0 1 0 0 0 0 1 0 1 1 1 0 0 0 0 |
|___|___|___|___|___|___|___|___|___|___|___|___|___|___|___|___|
<---------------------------------------------> <------------->
12 bit sample point is left justified rightmost
4 bits are
zero padded
应该注意，因为wave格式使用intel体系的little endian字节顺序，所以LSB（Least Significant Byte）在内存中出现在先：
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
| | | | | | | | | | | | | | | | | |
| 0 1 1 1 0 0 0 0 | | 1 0 1 0 0 0 0 1 |
|___|___|___|___|___|___|___|___| |___|___|___|___|___|___|___|___|
<-------------> <-------------> <----------------------------->
bits 0 to 3 4 pad bits bits 4 to 11
对多声道声音，（例如一个立体声波形文件），来自每一个声道的采样点数据被交织存放。例如，对于一个立体声波形来说，有两个声道的数据。文件中并不是先把 左声道的全部采样点数据放在文件前半部分，然后把右声道的全部采样点数据集中放在文件后半部分。实际的做法是将两个声道的数据“混合”放置，即：
左声道的第一个样点，右声道的第一个样点，左声道的第二个样点，右声道的第二个样点，左声道的第三个样点，右声道的第三个样点……左右声道的样点交替出现，这就是我们所说的“交织数据”。这样，当播放这些数据的时候，应该被同时播放的数据在文件中的位置总是相邻的。
所有需要被同时“播放”（也就是发送到数－模转换器）的样点，总称为一个“采样帧”。对立体声波形来说，每两个采样点构成一个采样帧。如下图所示：
sample sample sample
frame 0 frame 1 frame N
_____ _____ _____ _____ _____ _____
| ch1 | ch2 | ch1 | ch2 | . . . | ch1 | ch2 |
|_____|_____|_____|_____| |_____|_____|
对于一个单声道的波形来说，一个采样帧就由一个采样点构成，无需任何交织。对多声道的波形来说，应该按照下面所示的习惯顺序，来安排一个采样帧中的各个采样点的顺序。下面的每一幅图，展示了一种多声道波形文件中的一个采样帧中，各个采样点出现的习惯顺序。
channels 1 2
_________ _________
stereo | left | right |
|_________|_________|
1 2 3
_________ _________ _________
3 channel | left | right | center |
|_________|_________|_________|
1 2 3 4
_________ _________ _________ _________
| front | front | rear | rear |
quad | left | right | left | right |
|_________|_________|_________|_________|
1 2 3 4
_________ _________ _________ _________
4 channel | left | center | right | surround|
|_________|_________|_________|_________|
1 2 3 4 5 6
_________ _________ _________ _________ _________ _________
| left | left | center | right | right |surround |
6 channel | center | | | center | | |
|_________|_________|_________|_________|_________|_________|
一个采样帧中的各个采样点之间没有填充字节，各个采样帧之间也没有填充字节。注意上面的讨论中我们所说的都是非压缩的data chunk中的数据格式。还有一些data chunk中可能存储压缩过的数据，显然这种情况下需要解压缩，解压缩之后的数据还是严格遵守上述格式的。
Format chunk
Format (fmt) chunk描述了波形文件的基本参数，比如抽样频率，bit精度，声道数量。
#define FormatID 'fmt '
typedef struct {
ID chunkID;
long chunkSize;
short wFormatTag;
unsigned short wChannels;
unsigned long dwSamplesPerSec;
unsigned long dwAvgBytesPerSec;
unsigned short wBlockAlign;
unsigned short wBitsPerSample;
} FormatChunk;
ID总是"fmt "。chunkSize是chunk的长度，单位是字节，这个长度不包括ID和Size两个域所占用的8字节。针对不同的wFormatTag的取值， chunkSize也可能取不同的值。Wave数据可以以非压缩的格式存放，也可以用很多不同的压缩格式存放在data chunk内。压缩格式存放时，每一个采样点占用的字节数可能是各不相同的。wFormatTag指明数据存储时是否经过压缩。如果经过压缩 （wFormatTag的取值不是1），FormatChunk末尾会被追加更多的域，用以说明压缩格式，以便解压缩。这些关于压缩格式的信息，首先是一 个unsigned short类型数据，指明这个unsigned short之后还有多少字节的附加数据。压缩格式的数据还必须包括一个Fact chunk，这个chunk包括了一个unsigned long数据指明数据被解压缩之后包含多少个样点。压缩格式太多了，详细信息参考微软站点。当wFormatTag=1，用的就是非压缩格式。
wChannels：该声音文件中的声道个数。1－单声道，2－立体声，4－四声道声音，等等。多声道情况下的采样点，采样帧及其格式参见上面的叙述。
dwSamplesPerSec：采样帧频率，即每秒播放的采样帧个数。标准的采样帧频率有11025, 22050, 44100 Hz。但是也有其它非标准的采样帧频率被使用。
dwAvgBytesPerSec:每秒钟有多少帧被播放。dwAvgBytesPerSec被音乐播放工具用于估计顺畅播放声音所需的RAM缓冲区大小。这个值应该用下面的公式计算并四舍五入到最接近的整数上：
dwSamplesPerSec * wBlockAlign
wBlockAlign该用下面的公式计算并四舍五入到最接近的整数上：
wChannels * (wBitsPerSample / 8)
这个值是一个采样帧的大小，单位是字节。例如一个16bit立体声声音文件中的一个采样帧大小是4字节。
The wBitsPerSample指定一个采样点的数据精度是多少个bit。
详细的读写如下所示
#pragma once
class File
{
public:
File(void);
public:
~File(void);
BOOL Open(LPCTSTR lpFileName,DWORD dwDesiredAccess = FILE_WRITE_DATA|FILE_READ_DATA/*参考CreateFile*/);
DWORD Seek(LONG lDistanceToMove,DWORD dwMoveMethod=FILE_BEGIN/*参考SetFilePointer*/);
DWORD SeekToBegin( );
DWORD SeekToEnd( );
DWORD GetLength( ) const;
DWORD Read( LPVOID lpBuffer,DWORD nNumberOfBytesToRead);
DWORD Write(LPVOID lpBuffer,DWORD nNumberOfBytesToWrite);
protected:
HANDLE m_hFile;
};
#include "StdAfx.h"
#include <ASSERT.H>
#include "File.h"
extern DWORD g_dwLastError;
File::File(void)
{
m_hFile=INVALID_HANDLE_VALUE;
}
File::~File(void)
{
if (m_hFile!=INVALID_HANDLE_VALUE)
{
CloseHandle(m_hFile);
}
}
BOOL File::Open(LPCTSTR lpFileName,DWORD dwDesiredAccess)
{
m_hFile = CreateFile(lpFileName,dwDesiredAccess,FILE_SHARE_READ,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL);
return m_hFile!=INVALID_HANDLE_VALUE ? TRUE:FALSE;
}
DWORD File::Seek(LONG lDistanceToMove,DWORD dwMoveMethod/*参考SetFilePointer*/)
{
assert(m_hFile!=INVALID_HANDLE_VALUE);
return SetFilePointer(m_hFile,lDistanceToMove,NULL,dwMoveMethod);
}
DWORD File::SeekToBegin( )
{
assert(m_hFile!=INVALID_HANDLE_VALUE);
return SetFilePointer(m_hFile,0,NULL,FILE_BEGIN);
}
DWORD File::SeekToEnd( )
{
assert(m_hFile!=INVALID_HANDLE_VALUE);
return SetFilePointer(m_hFile,0,NULL,FILE_END);
}
DWORD File::GetLength( ) const
{
assert(m_hFile!=INVALID_HANDLE_VALUE);
return GetFileSize(m_hFile,NULL);
}
DWORD File::Read( LPVOID lpBuffer,DWORD nNumberOfBytesToRead)
{
assert(m_hFile!=INVALID_HANDLE_VALUE);
DWORD dwNumberOfBytesRead;
ReadFile(m_hFile,lpBuffer,nNumberOfBytesToRead,&dwNumberOfBytesRead,NULL);
return dwNumberOfBytesRead;
}
DWORD File::Write(LPVOID lpBuffer,DWORD nNumberOfBytesToWrite)
{
assert(m_hFile!=INVALID_HANDLE_VALUE);
DWORD dwNumberOfBytesWrite;
WriteFile(m_hFile,lpBuffer,nNumberOfBytesToWrite,&dwNumberOfBytesWrite,NULL);
return dwNumberOfBytesWrite;
}
#pragma once
#include "file.h"
class CWaveFile :
public File
{
public:
CWaveFile(void);
public:
~CWaveFile(void);
public:
void SetWaveFormat(WAVEFORMATEX *pwfx);
DWORD WriteWavFileHeader();
DWORD WriteWavData(LPBYTE pData,DWORD nSize);
private:
DWORD m_dwTotalBytes;
WAVEFORMATEX m_wfx;
};
#include "StdAfx.h"
#include "CWaveFile.h"
#include <AVIRIFF.H>
static const DWORD WAVE_FILE_HEAD_SIZE = sizeof(RIFFLIST) + sizeof(RIFFCHUNK) + sizeof(WAVEFORMATEX) + sizeof(RIFFCHUNK);
CWaveFile::CWaveFile(void)
{
m_dwTotalBytes = 0;
ZeroMemory(&m_wfx,sizeof(WAVEFORMATEX));
m_wfx.wFormatTag = WAVE_FORMAT_PCM;
m_wfx.nChannels = 2;
m_wfx.wBitsPerSample = 16;
m_wfx.nSamplesPerSec = 44100;
m_wfx.nBlockAlign = m_wfx.nChannels * m_wfx.wBitsPerSample / 8;
m_wfx.nAvgBytesPerSec = m_wfx.nSamplesPerSec * m_wfx.nBlockAlign;//每秒的数据量
m_wfx.cbSize = 0;
}
CWaveFile::~CWaveFile(void)
{
}
void CWaveFile::SetWaveFormat(WAVEFORMATEX *pwfx)
{
CopyMemory(&m_wfx,pwfx,sizeof(WAVEFORMATEX));
}
DWORD CWaveFile::WriteWavFileHeader()
{
BYTE Buffer[WAVE_FILE_HEAD_SIZE];
RIFFLIST *pRiffWave = (RIFFLIST *)Buffer;
RIFFCHUNK *pRiffFmt = (RIFFCHUNK *)(pRiffWave + 1);
RIFFCHUNK *pRiffData = (RIFFCHUNK *)(((BYTE *)(pRiffFmt + 1)) + sizeof(WAVEFORMATEX));
pRiffData->fcc = FCC('data');
pRiffData->cb = m_dwTotalBytes;
pRiffFmt->fcc = FCC('fmt ');
pRiffFmt->cb = sizeof(WAVEFORMATEX);
CopyMemory(pRiffFmt + 1, &m_wfx, sizeof(WAVEFORMATEX));
pRiffWave->fcc = FCC('RIFF');
pRiffWave->cb = m_dwTotalBytes + WAVE_FILE_HEAD_SIZE - sizeof(RIFFCHUNK);
pRiffWave->fccListType = FCC('WAVE');
SetFilePointer(m_hFile, 0, NULL, FILE_BEGIN);
DWORD dwWriten = 0;
BOOL bRet = WriteFile(m_hFile, Buffer, WAVE_FILE_HEAD_SIZE, &dwWriten, NULL);
if ((bRet == FALSE) || (dwWriten != WAVE_FILE_HEAD_SIZE))
{
return -1;
}
return 0;
}
DWORD CWaveFile::WriteWavData(LPBYTE pData,DWORD nSize)
{
DWORD nByteWrite = Write(pData,nSize);
m_dwTotalBytes+=nByteWrite;
return nByteWrite;
}<PRE>
![swmm与lisflood-fp源码如何一起编译 CMake命令[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)