Javascript 源于数据url（base64）的音频标记在播放音频之前不会完全加载

我有一个应用程序，可以在运行时将音频片段动态加载到音频标记中。它通过将音频转换为base64数据url并将其分配给标记的src属性来实现这一点

问题是音频标签在音频剪辑完全播放一次后才处理数据。此问题在标签上显示为（1）音频长度不足，（2）时间洗涤器禁用，（3）3点图标未显示。第一次播放音频剪辑后，这些功能将立即出现

我需要一种方法，让音频标签处理音频剪辑，一旦它被分配。用户需要能够下载音频并使用时间洗涤器快速前进，而不必被迫播放整个音频剪辑

我一直在寻找解决这个问题的办法。我试过

audioTag.preload=“auto”并调用
audioTag.load（）分配src后。我还让它放置了15分钟，以防加载速度太慢

如果base64数据url格式允许我绕过这个问题，我愿意使用它来替代它

谢谢你能提供的帮助

编辑：我在Chrome80和Firefox75中看到了这个问题

编辑：
我正在生成一个音频剪辑，并以两种方式将其分配给音频标记：（1）来自“文件”输入标记（2）来自MediaRecorder（连接到web音频api）

以下是“文件”输入标记加载：

const reader = new FileReader();
reader.onload = () =>
{
    const audioTag = document.getElementById("audioTag");
    audioTag.preload = "auto";
    audioTag.src = reader.result;
    audioTag.load();
};
reader.readAsDataURL(fileInputTag.files[0]);

以下是MediaRecorder加载：

mediaRecorder.onstop = () =>
{
    const blob = new Blob(audioChunks, {type : "audio/wav"});
    let reader = new FileReader();
    reader.onload = () =>
    {
        let audioTag = document.getElementById("rec");
        audioTag.preload = "auto";
        audioTag.src = reader.result;
        audioTag.load();
    };
    reader.readAsDataURL(blob);
};

我刚刚确定打开用audacity创建的wav文件可以正常工作。此问题仅在打开从MediaRecorder保存的音频文件时显示

我已经确定MediaRecorder实际生成的是“webM/opus”文件，而不是“wav”文件。研究强烈表明，“webM”是chrome上MediaRecorder唯一可用的录制选项（firefox也允许“ogg”）。没有“wav”文件支持。
我现在要发布一个“解决方案”。
我确定这个问题涉及我使用MediaRecorder生成音频剪辑，然后将音频剪辑保存到文件中。音频实际上是“webm/opus”格式。MediaRecorder不支持“wav”或“ogg”（至少在chrome中是这样）。此外，MediaRecorder创建的剪辑不可查看，只能在完全播放至少一次后才能删除或下载，如中所述

由于（1）剪辑不可观看（2）格式不兼容，MediaRecorder目前无法满足我的需要，我将寻找另一种录制音频的方法。
我已确定此问题涉及我使用MediaRecorder生成音频剪辑，然后将音频剪辑保存到文件中。音频实际上是“webm/opus”格式。MediaRecorder不支持“wav”或“ogg”（至少在chrome中是这样）。此外，MediaRecorder创建的剪辑不可查看，只能在完全播放至少一次后才能删除或下载，如中所述

我将寻找另一种录制音频的方法，因为MediaRecorder目前不足以满足我的需要，原因是（1）剪辑不可观看（2）格式不兼容。
是的，不要对此类内容使用base64编码。：-）当然也有其他选择（比如使用Blob），但是您没有提到您要做的具体内容，因此很难找到建议。为什么选择数据URI作为开始？这些动态音频数据来自哪里？请您提供一个简单的片段<代码>预加载
在正常情况下工作正常workflow@Brad.  我使用base64数据uri只是因为我在阅读的文章中看到了它的使用。我还尝试通过URL.createObjectURL加载blob，但没有解决问题。然而，我最近确定是音频数据本身造成了问题。如果您好奇的话，请查看我发布的答案。是的，不要使用base64编码进行类似的操作。：-）当然也有其他选择（比如使用Blob），但是您没有提到您要做的具体内容，因此很难找到建议。为什么选择数据URI作为开始？这些动态音频数据来自哪里？请您提供一个简单的片段<代码>预加载

在正常情况下工作正常workflow@Brad. 我使用base64数据uri只是因为我在阅读的文章中看到了它的使用。我还尝试通过URL.createObjectURL加载blob，但没有解决问题。然而，我最近确定是音频数据本身造成了问题。如果你好奇，请看我贴出的答案。嗨，乔纳森，我曾经创建了一个名为。它旨在支持与MediaRecorder相同的API，同时允许自定义编解码器。例如，您可以使用它对WAV文件进行编码。我希望有帮助。哦，谢谢！我会看一看，让你知道它是怎么回事。嗨，乔纳森，我曾经创建了一个名为。它旨在支持与MediaRecorder相同的API，同时允许自定义编解码器。例如，您可以使用它对WAV文件进行编码。我希望有帮助。哦，谢谢！我会看一看，然后告诉你进展如何。