使用ffmpeg，shntool和sox连接多个24位96 kHz wav音频文件

我试图连接15个wav音频文件，记录为24位，96kHz，线性PCM。我用ffmpeg，shntool和sox进行了实验，结果各不相同。

这些文件是由Zoom H2n记录器创建的，它将连续15小时的记录分成几个文件（实时）以适应SD存储卡规格。

前14个文件分别为2,147,385,344字节（1：02：08.04及时），最后一个文件为1,838,248,046字节（时间为53：11.35）。原始文件报告的比特率为4,608 kb / s（使用ffmpeg -i）。

使用ffmpeg

使用文件名创建文本文件：

printf "file '%s'\n" ./*.WAV > mylist.txt

连接文件：

ffmpeg -f concat -i mylist.txt -c copy output-ffmpeg.wav

这将生成一个31,901,151,444字节的文件，但报告时间仅为53:08。ffmpeg -i报告的比特率为80,049 kb / s，远远高于原来的4,608 kb / s。

使用shntool

加入文件：

shntool join -r none 01.wav 02.wav [etc]

这将生成一个31,901,151,386字节的文件 - 与ffmpeg连接不同 - 但也报告为53：08.16及时。同样，ffmpeg -i报告的比特率为80,049 kb / s，远远高于原来的4,608 kb / s。

使用Sox

连接文件：

sox 01.wav 02.wav [etc] output-sox.wav

这将生成一个31,901,151,422字节的文件 - 与ffmpeg和shntool不同 - 但报告为01：02：08.26及时。ffmpeg -i报告的比特率为68,452 kb / s，远远高于最初的4,608 kb / s，但与ffmpeg或shntool转换不同。

问题

1）如何让文件反映实际时间？将这个31 Gb / ~15小时的录音带入认为仅长约53分钟的音频软件可能会有问题。

2）为什么三个连接文件大小不同？是否有我应该使用的标志或设置，例如，由于某种原因填充长度？不同的文件大小是否为文件认为它们只有53:08或01:02:08长的线索？

当我第一次看到53:08时，我想，啊，它将最终文件的时间长度写入标题 - 但最终文件的时间长度实际上是53:11。当我第一次看到01：02：08.26时，我想，啊，它正在写第一个文件的时间长度，但遗憾的是，没有（接近但不准确）。

似乎我最好的线索是连接文件的错误（？）比特率。我很惊讶流副本或文件串联改变了这一点。也许这只是一个元数据错误？

.wav是一种RIFF 文件格式（msdn）

RIFF块数据的大小以32位存储。（最大无符号值为4 294 967 295）

RIFF限制为每个文件约4.2 GBytes。

当软件创建一个非常大的RIFF块时，其存储大小为32位值。

在某些时候，会发生整数溢出，并且会丢弃更高的数字位：

示例文件：6.220 GBytes / 3:00:00 / 96000 Hz / 24 bit / 2 channels / 4608 kbit / s

Real file size(hex):              01 72 C9 E0 86  (6 220 800 134)
Readed from RIFF header(hex) :       72 C9 E0 7E  (1 925 832 830)

Real file size(binary):            1 01110010 11001001 11100000 10000110  //33 bits
Readed from RIFF header(binary):     01110010 11001001 11100000 01111110  //32 bits

01 这是丢弃的部分。

ffprobe报告：

Duration: 00:55:43.46, bitrate: 14884 kb/s
 Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 96000 Hz, 2 channels, s32 (24 bit), 4608 kb/s

FFprobe错误的持续时间/比特率

FFprobe无法在文件中找到任何元数据并尝试从真实数据中计算它：

1. 一个比特率流：4608 kbit / s（96000 Hz * 24 bit * 2 chan）
2. RIFF块大小：1 925 832 830（是的，但是错误的：D）

持续时间将是（整个块大小除以比特率）：

1 925 832 830 / (4 608 000 / 8) = 3343.459 seconds

/ 8是因为比特率是每秒位数（一个字节是8位）

3343.459正好是00：55：43.459

（平均值？）整个文件的比特率是SizeOfFile / TotalSeconds：

6 220 800 134 / 3343.459 = 1860588.1316 字节 s / s（14884705.053 bit s / s）

如何获得一个大文件？

使用其他格式来存储它，例如：

FLAC / .rf64 / .w64 /等。

使用ffmpeg连接文件（FFmpeg Wiki Page Concatenate）：

ffmpeg -f concat -i mylist.txt -c:a flac output-ffmpeg.flac

这里mylist.txt是

file '/path/to/file1.wav'
file '/path/to/file2.wav'
file '/path/to/file3.wav'

已经有大WAV文件？

你可以玩它。整个。随便一招。
我们将RIFF数据块的大小设置为0。这会导致一些（？）音频播放器读取整个数据块（直到文件末尾？）。

来自编辑文件的FFprobe报告：

Duration: 03:00:00.00, bitrate: 4608 kb/s
 Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 96000 Hz, 2 channels, s32 (24 bit), 4608 kb/s

注意：在HEX编辑器中保存文件时，不需要重写完整文件。

1. 下载免费的HEX编辑器（例如HxD）
2. 制作标记字节的屏幕截图或副本。（作为备份）
3. 填写00。
4. 如果使用HxD：立即按下save然后Cancel按钮（以防止创建完整备份副本）
5. 打开。（在VLC / MPC-HC中测试。但WMP失败：D）

但是 如果.WAV 在文件末尾有一些元数据，FLAC将丢弃错误。
使用Audacity进行测试。使用HEX编辑器检查并在文件末尾找到元数据。

FLAC：ERROR: got partial sample
但文件的长度为2:59:59秒。没有md5校验和。
这意味着我们没有真正的 flac文件（读取已损坏）。
但可读。