音频样本的第一序列以单声道,PCM格式,16位和96,000 Hz的格式从浏览器中以JavaScript记录。我使用ajax通过JavaScript FormData对象将此音频文件作为Blob写入服务器。
这些是raw audio samples.当我从Web服务器的目录列表中检索音频时,我收到了第二个音频样本序列。它已被下采样至48000 Hz,并且采样已更改。使用什么编码器?
服务器端PHP代码:
$input = $_FILES['audio']['tmp_name']; //audio blob
$output = $_POST['filename'];
if(move_uploaded_file($input, $output))
exit('Audio file Uploaded');
客户端JavaScript代码:
function send_audio(fn, blob){
var formData = new FormData();
formData.append("filename", fn);
formData.append('audio', blob);
$.ajax({
url:'save_audio.php',
type:'post',
data: formData,
contentType:false,
processData:false,
cache:false,
success: function(data){
console.log("send_audio success!");
console.log(data);
}
});
}
目前尚不清楚,请考虑以下事项:
((1)尝试16位而不是每个样本32位(可能会有所帮助)。
无需以每个样本32位的方式记录这些音频样本。这意味着您正在使用4个字节来记录一个适合2个字节(16位)的样本值。
您的最大值是30465
(字节x77 x01
),最小值是-32513
(字节x80 xFF
)。注意那些值适合两个字节吗?通过使用4个字节,您可以制成x00 x00 x77 x01
。浪费了多余的存储空间00
。
两个字节保持65535
的最大值。甚至将32767
和+32767
分为两部分,甚至-32767
。
((2)确保在字节编码(十六进制)和数字编码(整数)之间没有混淆。
字节以十六进制形式写入文件。从整数转换为十六进制格式时,您的值似乎混乱了。同样是16位与32位的
您的数字中的一些示例与2字节(16位)十六进制相比:
FIRST SEQ: SECOND SEQ:
value | hex | value | hex
100 00 64 612 02 64
553 02 29 41 00 29
203 00 CB -309 FE CB
-409 FE 67 103 00 67
68 00 44 836 03 44
953 03 B9 185 00 B9
154 00 9A -102 FF 9A
-127 FF 81 385 01 81
注意,当整数100
的值写为十六进制(字节值)时,它变为字节x64
,由于某种原因,在2
前面添加了64
,现在使其x0264
转换为612
的整数值。
在第二序列中,这些额外的02
和FE
等来自哪里?为什么如果第一序列的十六进制具有00
,那么对于第二序列的十六进制,现在又添加了一些额外内容?甚至反之亦然(第一个=某物,然后第二个=某物被移除,成为00
)?
您需要仔细检查您的recording代码。它会增加一些增加的记录值吗?因为,正如您所知,2
后接3
,并且该模式出现在第二个序列中。同样正确的是FE
后跟FF
(因此,在FE
之前应是FD
,FC
,FB
,FA
等)。
如果您仍然无法解释,则:
以其他人的正常方式以44,100 Hz的频率记录16位。然后,如果简单的设置可行,则以后变得复杂。为什么仍要32位和96,000 Hz?这是科学检验吗?
使用十六进制编辑器从两侧查看您的字节(通过JS保存的blob文件,通过PHP下载的文件),并比较两个文件之间的所有更改。
显示您的录制代码的状态/方式。
共享“我从Web服务器检索音频的字节”(另存为文件)进行检查。
也许其他人可以帮助您。我不使用html表单,所以也许其中也有POST
数据类型的编码选项?