转换为原始音频文件是否保留以前的采样率？
好的。我正在尝试了解音频和压缩。我有一个基本问题，但我在互联网上搜索尚未找到答案。
我知道有带有标题信息的自描述格式。如果我用 sox 将不同的文件转换为“原始”格式，我认为为它们提供相同数量的“通道”和“采样率”是否错误？
我想我在想生食将是伟大的“中和剂”。难道不是这样吗？就像您可以将所有文件视为相同的原始格式文件一样吗？
维基百科说...
RAW 音频格式或只是 RAW 音频 一种计算机存储格式 原始形式的未压缩音频。 大小与 WAV 或 AIFF 相当，RAW 音频文件不包含任何标头 信息（采样率、位深度、 字节序或通道数）。数据 可以用 PCM、IEEE 754 或 ASCII。[需要引用]
http://en.wikipedia 上还有一些有关文件格式的好信息.org/wiki/Audio_file_format
说明 我需要连接可能以不同数量的通道和采样率开始的 mp3 文件。老实说，我不知道我最终想要多少个频道。我正在尝试将不同的文件与 sox 结合起来。但是，sox 需要文件具有相同的文件格式。因此，我希望让它们采用“相同的文件格式”，这意味着相同的通道数和采样率。
然而，现在看来，raw可能只是这两项，但删除了自我描述的标题信息？换句话说，转换为原始格式的 mp3 文件是否保留相同的属性（采样率和通道数）？
OK. I'm trying to learn about audio and compression. I have a fundamental question that I haven't found the answer to yet scouring the internet.
I know that there are self describing formats with header information. If I convert different files into "raw" format with sox, am I wrong in thinking that gives them the same number of "channels" and "sample rate"?
I guess I was thinking that raw would be the great "neutralizer." Is this not the case? Like you could treat all files as if they were the same if they were in raw format?
Wikipedia says...
RAW Audio format or just RAW Audio is
a computer format for storing
uncompressed audio in raw form.
Comparable to WAV or AIFF in size, RAW
Audio file does not include any header
information (sampling rate, bit depth,
endian, or number of channels). Data
can be written in PCM, IEEE 754 or
ASCII.[citation needed]
There is also some good information on file format in general at http://en.wikipedia.org/wiki/Audio_file_format
Clarification
I need to concatenate mp3 files that may start out with different numbers of channels and sampling rates. I don't honestly know how many channels I want to end up with. I am trying to combine the different files with sox. However, sox needs the files be in the same file format. So, I was hoping to get them in the "same file format" meaning the same number of channels and sampling rate.
However, now it seems that raw might just these two items but remove the self describing header information? In other words, an mp3 file converted to raw, retains the same properties (sampling rate and number of channels)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您想要做的是：
RAW 文件与 WAV 文件相同，只是它们没有告诉您格式的标头。因此，您可以完全忘记 RAW 文件，除非您碰巧知道该文件的音频格式，因此不需要该标头信息。
What you want to do is:
RAW-files are the same as WAV-files, only that they have no header that tells you the format. So you can completely forget about RAW-files unless you happen to know the audio format of the file anyway, and therefore don't need that header information.
原始音频文件没有任何“标准”。它们可以通过多种方式、不同的比特率和通道数进行编码。如果您正在尝试找到一种在格式之间转换音频的方法，那么这不适合您。
There isn't any "standard" for raw audio files. They can be encoded any number of ways, with different bit rates and channel counts. If you're trying to find a way to convert audio between formats, this is not the answer for you.
即使速率不同，MP3 文件也可以直接连接，&c。您可能有其他原因需要原始数据或 wav（原始 + 标头），但您可以在没有解码/编码步骤的情况下完成此操作。
我纠正了。我通过后端编程（脚本）管理的许多 MP3 文件确实改变了它们的帧头、比特率等。然后我们通过另一个商业产品将其流式传输，但显然表示产品尊重每一个标头！
当我通过 Google Chrome 和 QuickTime 尝试相同的输入流时，似乎只有第一个标头受到尊重并在整个文件中被假定！谁会响？
所以我在这里学到了一个重要的教训，谢天谢地主播必须预检 MP3 流！在这种情况下，我认为使用您在输出中期望的最大通道数解码为“原始”是可行的方法，然后您可以缩混到编码时所需的通道数。
MP3 files can be directly concatenated even with varying rates, &c. You may have other reasons for wanting raw data or wav (raw + header), but you can do this without a decode/encode step.
I stand corrected. A lot of the MP3 files I manage via back-end programming (scripts) indeed vary their frame headers, bit rates, et cetera. We then stream it through through another commercial product BUT APPARENTLY said product respects each and every header!
When I tried the same input stream through Google Chrome as well as QuickTime it appears as only the very first header is respected and assumed throughout the whole file! Who'da thunk?
So I learned a big lesson here, thank goodness the streamer must pre-flight the MP3 stream! In this case I think decoding to "raw" with the maximum # of channels that you expect in the output is the way to go, then you can downmix to the # of channels needed upon encoding.