转篇东东
一、综述
WAVE文件作为多媒体中使用的声波文件格式之一，它是以RIFF格式为标准的。
RIFF是英文Resource Interchange File Format的缩写，每个WAVE文件的头四个
字节便是“RIFF”。
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' |
------------------------------------------------
图1 Wav格式包含Chunk示例
其中除了Fact Chunk外，其他三个Chunk是必须的。每个Chunk有各自的ID，位
于Chunk最开始位置，作为标示，而且均为4个字节。并且紧跟在ID后面的是Chunk大
小（去除ID和Size所占的字节数后剩下的其他字节数目），4个字节表示，低字节
表示数值低位，高字节表示数值高位。下面具体介绍各个Chunk内容。
PS：
所有数值表示均为低字节表示低位，高字节表示高位。
二、具体介绍
RIFF WAVE Chunk
==================================
| |所占字节数|具体内容 |
==================================
| ID |4 Bytes | 'RIFF' |
----------------------------------
| Size|4 Bytes | |
----------------------------------
| Type|4 Bytes | 'WAVE' |
----------------------------------
图2RIFF WAVE Chunk
以'FIFF'作为标示，然后紧跟着为size字段，该size是整个wav文件大小减去ID
和Size所占用的字节数，即FileLen - 8 = Size。然后是Type字段，为'WAVE'，表
示是wav文件。
结构定义如下：
struct RIFF_HEADER
{
char szRiffID;// 'R','I','F','F'
DWORD dwRiffSize;
char szRiffFormat; // 'W','A','V','E'
};
Format Chunk
====================================================================
| | 字节数| 具体内容 |
====================================================================
| ID |4 Bytes| 'fmt ' |
--------------------------------------------------------------------
| Size |4 Bytes| 数值为16或18，18则最后又附加信息 |
------------------------------------------------------------------------
| FormatTag |2 Bytes| 编码方式，一般为0x0001 | |
-------------------------------------------------------------------- |
| Channels |2 Bytes| 声道数目，1--单声道；2--双声道 | |
-------------------------------------------------------------------- |
| SamplesPerSec |4 Bytes| 采样频率 | |
-------------------------------------------------------------------- |
| AvgBytesPerSec|4 Bytes| 每秒所需字节数 | |===> WAVE_FORMAT
-------------------------------------------------------------------- |
| BlockAlign |2 Bytes| 数据块对齐单位(每个采样需要的字节数) | |
-------------------------------------------------------------------- |
| BitsPerSample |2 Bytes| 每个采样需要的bit数 | |
-------------------------------------------------------------------- |
| |2 Bytes| 附加信息（可选，通过Size来判断有无） | |
------------------------------------------------------------------------
图3Format Chunk
以'fmt '作为标示。一般情况下Size为16，此时最后附加信息没有；如果为18
则最后多了2个字节的附加信息。主要由一些软件制成的wav格式中含有该2个字节的
附加信息。
结构定义如下：
struct WAVE_FORMAT
{
WORD wFormatTag;
WORD wChannels;
DWORD dwSamplesPerSec;
DWORD dwAvgBytesPerSec;
WORD wBlockAlign;
WORD wBitsPerSample;
};
struct FMT_BLOCK
{
charszFmtID; // 'f','m','t',' '
DWORDdwFmtSize;
WAVE_FORMAT wavFormat;
};
Fact Chunk
==================================
| |所占字节数|具体内容 |
==================================
| ID |4 Bytes | 'fact' |
----------------------------------
| Size|4 Bytes | 数值为4 |
----------------------------------
| data|4 Bytes | |
----------------------------------
图4Fact Chunk
Fact Chunk是可选字段，一般当wav文件由某些软件转化而成，则包含该Chunk。
结构定义如下：
struct FACT_BLOCK
{
charszFactID; // 'f','a','c','t'
DWORDdwFactSize;
};
Data Chunk
==================================
| |所占字节数|具体内容 |
==================================
| ID |4 Bytes | 'data' |
----------------------------------
| Size|4 Bytes | |
----------------------------------
| data| | |
----------------------------------
图5 Data Chunk
Data Chunk是真正保存wav数据的地方，以'data'作为该Chunk的标示。然后是
数据的大小。紧接着就是wav数据。根据Format Chunk中的声道数以及采样bit数，
wav数据的bit位置可以分成以下几种形式：
---------------------------------------------------------------------
| 单声道| 取样1 | 取样2 | 取样3 | 取样4 |
| |--------------------------------------------------------
|8bit量化 | 声道0 | 声道0 | 声道0 | 声道0 |
---------------------------------------------------------------------
| 双声道| 取样1 | 取样2 |
| |--------------------------------------------------------
|8bit量化 |声道0(左)|声道1(右)|声道0(左)|声道1(右)|
---------------------------------------------------------------------
| | 取样1 | 取样2 |
| 单声道|--------------------------------------------------------
| 16bit量化 | 声道0 |声道0 | 声道0 |声道0 |
| | (低位字节)| (高位字节)| (低位字节)| (高位字节)|
---------------------------------------------------------------------
| | 取样1 |
| 双声道|--------------------------------------------------------
| 16bit量化 |声道0(左)|声道0(左)|声道1(右)|声道1(右)|
| | (低位字节)| (高位字节)| (低位字节)| (高位字节)|
---------------------------------------------------------------------
图6 wav数据bit位置安排方式
Data Chunk头结构定义如下：
struct DATA_BLOCK
{
char szDataID; // 'd','a','t','a'
DWORD dwDataSize;
};
不同意cfuer兄关于因为“jitter不能像电流一样作为物理量存在”，所以jitter就不能作为信号载体的论断。
电磁波的振幅、频率和相位都不能独立于电磁波存在，但是它们却都是很常见的信号载体。调幅、调频或调相通信，本质上就是通过精确控制（调制）电磁波的振幅、频率或相位的误差（可控变化）来传递信息啊。当然“精确控制”的“误差”就不能再叫做误差了，过河的卒子，叫信号了。Jitter虽然不能独立于基础信号存在，那么我们传送一个空的基础信号不就行了，或者传一个不空的，还买一送一啦，jitter上面送音频，载波上面送美女照，有声有色的多好？
呵呵，这些都是在荒缪前提下的荒唐推论（wild assumption，wild imagination )，本身没什么错，只是千万当不得真啊。科学技术上只要你说明是assumption，怎么assume都行，怕的是不小心把assumption错当成truth或reality了，科学技术上的失误多半是这么来的。不过这个接受任何assumption的开放心态是需要的，没有这样的开放心态，像虚数（负数的方根）、4维空间、波粒二像性这些“荒谬”的概念都无法产生和存在，如果没有这些概念，现代科学和现代技术都是不可想象的啊。
网站怎么突然这么慢啦？不玩了，看电影去了。
原帖由 cfuer 于 2009-8-1 21:02 发表 http://www.headphoneclub.com/bbs/images/common/back.gif
你这个逻辑真是混乱:L 。
lz说明jitter不可传递是这样表述的：jitter如果可以传递，我们早就开发出调制技术让他承载信息了。即jitter可以传递与我们没法把它作为信息载体是矛盾的。
我的反驳是：jitter不能像 ...
我理解你的意思了。你说的 "控制JITTER" ,指的是对JITTER进行调制，以让它表达某种信息。换句话说，给JITTER加个函数，让它对应到某个现实的物理量。
那我告诉你，你多虑了 ，而且，考虑问题的正常逻辑也不是这样。
试想，如果JITTER可以透过内存、硬盘、网络等等介质稳定的传递，那么它将会是多么有价值的一个信息通道？对此进行开发利用，是绝对有非常大的价值的。
而你现在说jitter无法调制，只不过是你还不知道它的调制方法罢了，因为到目前为止，也没有任何人去开发过JITTER的调制方法。
就像无线电在被利用之前，没有人知道它的调制方法一样。
但这里的前提是，无线电的确是可以传递信息的。而JITTER呢？不能。
所以你的逻辑真的很奇怪，就好象在说，因为现在还没有发明出高达机器人，所以高达机器人是不可能被发明的一样。
俺有一个疑问：JITTER作为寄生的误差信号，等同于随机噪声，是否只有统计上的意义，不可能作为控制信号来利用的？:)
jitter是否可以作为信号载体源于其定义。和是否物理量关系不大。
假设0.5ui以下代表0，以上代表1。那么在信源和信道都需需控制精确的抖动。这个时候的jitter还是原来的jitter吗？cfuer的话”物理量真实值和我们的期望值之间的差异“，你都控制了，还有什么和期望值的差异。
如果我们把jitter狭义地只是指抖动的话，抖动的确可以用于传送信号的。
绕来绕去的，说得累 :(
jitter是否可以用于传送，关键在于你把jitter看成是抖动还是”和期望值之间的差异“。目前为止cfuer兄对jitter的理解更符合通信的实际。
哈哈，兄弟们热火朝天的开始讨论jitter的调制了。罪过罪过，我瞎举一个荒唐例子，浪费大家很多时间，不务正业。我要是说“如果石头能吃，人们早就吃着石头了”，大家不会忙着争论石头的烹调技术吧？算了别争这个啦。
这样吧，下面这话大家看能不能接受，可以的话我们先把这个话题放一放，等那个“如果”实现了，我们再继续讨论jitter调制的问题？
Statement：jitter可以看作是基础信号上的甚高次谐波，因为包含从低次到非常高次谐波，所以它的潜在带宽也很高。谐波都是正弦波，调制正弦波没有困难吧？问题是，要精确描述Jitter的波形，恐怕我们需要分离到几十次上百次谐波，这是为什么没有创意的brutal force的jitter的控制是代价上不允许的。频率提升上百倍，一切相关技术、器材的成本提升多少倍啊？有钱整这么高频不能直接整高频PCM啊，把SRC全扔马桶里抽掉不好吗？当然，我之前说的jitter调制技术可不是这么傻笨的技术哦，因为“如果”记录和传递jitter的前提技术是如此之神奇，“那么”我的调制技术也一定是一样灵巧神奇的技术，否则就不能算奇迹啦。一条街那么长的批萨饼有什么稀奇啊，能当发烧音箱用的批萨饼才神奇呢。
cfuer兄，你可千万别再说我那个百次谐波上也有他自己的jitter哦，你要是这样说我只好哭啦。不过哭完后我还会告诉你百次谐波的百次谐波能精确描述百次谐波上的jitters，而将来的神奇调制法可以更简单可靠的调制百次谐波上的jitter ：-）
唉，趁时间还早，感觉看电影啦。
原帖由 cfuer 于 2009-8-1 22:44 发表 http://www.headphoneclub.com/bbs/images/common/back.gif
按您的意思，任何计划都不需要考虑可行性。
“你还没做，怎么知道不能做成功呢！”
抱歉，这个太励志了……而且和逻辑无关。:L
当然需要考虑可行性，但更重要的前提是计划是否有意义。
到现在连JITTER能否稳定传递都还没谱，你就让我告诉你它的调制方法了？
正如LZ所言，你连太阳都没给我，就要我用它给你包蛋黄粽？
原帖由 pcear 于 2009-8-1 22:26 发表 http://bbs.headphoneclub.com/images/common/back.gif
jitter是否可以作为信号载体源于其定义。和是否物理量关系不大。
假设0.5ui以下代表0，以上代表1。那么在信源和信道都需需控制精确的抖动。这个时候的jitter还是原来的jitter吗？cfuer的话”物理量真实值和我们的期 ...
"假设0.5ui以下代表0，以上代表1"，反对！反对！pcear兄你太大手大脚铺张浪费了，都像你这样共产主义20年能实现得了吗？Jitter这样的神奇载体怎么能这样调制，这么宽的带宽至少也是mod2^100000的调制吧，一个波特不塞进去个把整个数据包怎么对得起党的事业啊？
原帖由 听风 于 2009-8-1 22:23 发表 http://bbs.headphoneclub.com/images/common/back.gif
俺有一个疑问：JITTER作为寄生的误差信号，等同于随机噪声，是否只有统计上的意义，不可能作为控制信号来利用的？:)
噪声和失真是很不一样的，噪声是比较随机的，失真是有模式（pattern）的。Jitter造成的artifacts是失真，不是噪声。实际上随机的噪声很多情况下是个好东西，而失真则是一无是处非常讨厌的东西。
应用领域有很多场合故意利用人工制造的噪声去取代或者掩盖失真或者其它更难听的噪声，有很好的效果。大名鼎鼎的Dithering其实就是这样的技术，它在任何涉及AD转换和数字处理、截取的领域都是有基础重要性的，没有它，几乎就没有数字音频和数字视频行业了。
哈哈，我回去为电话线传输10m努力去 :lol
原帖由 pcear 于 2009-8-1 22:26 发表 http://www.headphoneclub.com/bbs/images/common/back.gif
jitter是否可以作为信号载体源于其定义。和是否物理量关系不大。
假设0.5ui以下代表0，以上代表1。那么在信源和信道都需需控制精确的抖动。这个时候的jitter还是原来的jitter吗？cfuer的话”物理量真实值和我们的期望值之间的差异“，你都控制了，还有什么和期望值的差异。
如果我们把jitter狭义地只是指抖动的话，抖动的确可以用于传送信号的。
绕来绕去的，说得累 :(
说来说去，LZ原来不就是这个意思吗？用远远高于原始频率的频率去描述原始频率的JITTER，控制原始频率的JITTER，那为什么不直接把原始频率提高呢？
再举LZ说的例子，你用一把精确的尺去描述一把粗糙的尺的误差，那为什么不直接用精确的尺呢？
而CFUER是什么意思？他的意思是，这把精确尺造不出，不存在。
