wav是微软针对音频提供的一种文件，其本质上和qt类文件（如mp4 mov）是一样的，都是“容器”类文件。但凡是容器类的文件其关注的点就是制定规则，一切按规则来（wav中就是速率、时长、编码类型等）。这个案例的特殊之处是其在生成wav的时候又生成了sbc文件，两个文件排队交叉写入，导致大量碎片。

故障存储:32G镜像文件（品牌不详录音笔）

故障现象:

使用录音笔常见的FAT32文件系统，客户在查看数据时发现一个重要的约1小时多的wav文件不见了，其表示没有做过删除操作。但是通过判断大概率是被删除了。

故障分析:

此录音笔同时生成两个同名文件(扩展名一个为wav, 一个为sbc),wav是标准容器类文件，而sbc不太清楚，经过百度发现是一种压缩格式。这也很好的解释了两个文件 wav的容量大于sbc,可能sbc是用于备份或有其它特殊用处，具体原因不详。如下图可以看到两个文件的创建时间是相同的，从winhex列出来的簇列表可以发现，两个文件是排队交叉写入，碎片数量巨大。这类文件一般删除后,fat表会清0，这样就得不到表链了。所以只能通过底层文件结构来分析。

如下图两

故障处理:

先来看看RSTUDIO的扫描结果，由于FAT表清0目录项也破坏了，所以结果惨不忍睹。如下图，可以看到带目录的文件内容中也没有发现删除的文件，按类型找出来的都不正常。

通用类恢复程序如果无法定位，就只能通过文件结构、编码等来入手。想要定位文件就需要确定文件在存储底层的位置，经过和客户沟通得知其所需要的那个文件位于下图中所选文件之后，位于下一个文件之前。

抱着试一试的态度，在这个区间内搜索wav文件头RIFF标识，结构发现一个文件头,可以看到winhex已经明确标识其位于“空余空间”区域，证明这个文件确实是被删除了。而结合存在的文件，发现如下规律。

1. wav和sbc存在簇交叉，wav除文件头外，其它多数为两个簇一个单位（是否有规律待定，因为写入的时候有很多种可能管理程序只负责发送包写入的工作是由FAT32来完成的，除非发送的包是固定长度，这个相对音频来说是比较难控制的）。
2. 两个文件交叉存储完成后就是下一组文件的起始，这样就能判断大致的文件所处区域为当前文件头到下一个文件头。

根据上边两点分析，先提取了文件区域，然后尝试使用两簇进行合成，结果文件在播放时有啸叫声，这种大概率说明第1条不可信，其没有规律性。接下来研究两种编码的不同之处，看能否找到突破点。结果发现WAV使用的是PCM编码，这是一种纯高清编码，不压缩，主打的就是高清音质，但是占用空间大。而SBC则是一种压缩格式，主打是节省空间，压缩类的无论是视频还是音频，原始数字信息肯定是要打散的，可以通过判断PCM音频特征码来进行碎片剥离和重组。还好是两种不同格式交叉，如果是相同编码就只能手工一点点拼了！

定了方案就好处理了，直接写程序来实现，文件不算大，233M的区域中成功分离出154M的WAV文件，经过播放文件完成正常，至此恢复工作完成。