ExtAudioFileSeek 和 ExtAudioFileWrite 一起写入同一个文件
我遇到一种情况，我可以通过从轨道末尾获取一些经过操作的缓冲区并将它们写入输出文件的开头来保存音频的后处理过程。
我原本以为我可以通过使用 ExtAudioFileSeek 重置写入指针来实现这一点，当我在文档中看到这一行时，我正要实现它。
Ensure that the file you are seeking in is open for reading only. This function’s behavior with files open for writing is undefined.
现在我知道我可以关闭文件以进行写入，然后重新打开它，但过程比这稍微复杂一些。我所做的部分操作是从我正在写入的文件中的缓冲区中读取数据。整体过程如下所示：
- 从读取文件的末尾读取缓冲区
- 从写入文件的开头读取缓冲区
- 处理缓冲区
- 将缓冲区写回写入文件的开头，覆盖我在步骤 2 中读取的缓冲区
逻辑上，这可以在 1 遍内完成，没有问题。以编程方式，我怎样才能实现同样的事情而不破坏我的数据，变得效率较低（与我的目标相反）或潜在地破坏宇宙？
I have a situation where I can save a post-processing pass through the audio by taking some manipulated buffer from the end of the track and writing them to the beginning of my output file.
I originally thought I could do this by resetting the write pointer using ExtAudioFileSeek, and was about to implement it when I saw this line in the docs
Ensure that the file you are seeking in is open for reading only. This function’s behavior with files open for writing is undefined.
Now I know I could close the file for writing then reopen it, but the process is a little more complicated than that. Part of the manipulation I am doing is reading from buffers that are in the file I am writing to. The overall process looks like this:
- Read buffers from the end of the read file
- Read buffers from the beginning of the write file
- Process the buffers
- Write the buffers back to the beginning of the write file, overwriting the buffers I read in step 2
Logically, this can be done in 1 pass no problem. Programmatically, how can I achieve the same thing without corrupting my data, becoming less-efficient (opposite of my goal) or potentially imploding the universe?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，正如您所说，使用单个音频文件进行读取和写入可能会导致宇宙崩溃，或者至少会导致其他问题。我认为解决这个问题的关键在于步骤4，你应该将输出写入一个新文件，而不是尝试“回收”初始写入文件。处理完成后，您可以简单地废弃中间写入文件。
或者我误解了这个问题？
哦，还有，如果您实时执行此操作，则应该使用
ExtAudioFileWriteAsync而不是ExtAudioFileWrite进行写入。否则 I/O 负载将导致音频丢失。Yes, using a single audio file for both reading and writing may, as you put it, implode the universe, or at least lead to other nastiness. I think that the key to solving this problem is in step 4, where you should write the output to a new file instead of trying to "recycle" the initial write file. After your processing is complete, you can simply scrap the intermediate write file.
Or have I misunderstood the problem?
Oh, and also, you should use
ExtAudioFileWriteAsyncinstead ofExtAudioFileWritefor your writes if you are doing this in realtime. Otherwise the I/O load will cause audio dropouts.