有人要我從 40 分鐘的講座錄音中發出聲音，這樣它就可以在手機上通勤。 我先做了顯而易見的事情，即將其轉換為 MP3，它花了幾分鐘，製作了一個比視訊內部已經存在的音訊稍大的檔案。 然後我先做了我應該做的事情，然後把曲目複製出來。 不到一秒鐘，檔案就更小了，音訊與錄音機捕獲的音訊有點相同。 第二種方法不是技巧或捷徑。 這是文件格式的設計目的，幾乎每個回答這個問題的轉換器都會忽略它。
TL;DR: MP4 或 MOV 通常帶有 AAC 音訊，而 M4A 是同一個系列的僅音訊容器中的相同 AAC，因此可以直接複製該軌道，無需解碼，也沒有遺失。 在此處以 60 秒的測試剪輯測量：副本在 0.04 秒內完成，提取的音訊串流與視訊內的流具有相同的 MD5。 以 192 kbps 的速度將相同的音訊編碼為 MP3 需要 0.36 秒，產生一個大 48% 的檔案，並經歷了第二輪有損壓縮它不需要的東西。 除非下游有任何拒絕，否則選擇 M4A，在編輯器或轉錄機需要 PCM 時選擇 WAV，然後選擇 MP3 僅用於讀取其他內容的裝置。 那個 抽象器 在瀏覽器標籤中完成所有三個，因此記錄的會議永遠不會離開機器。
MP4的音軌裡面是什麼？
MP4 是一個容器，這意味著它是一個歸檔系統而不是格式。 裡面是單獨的流：一個拿著壓縮的圖片，一個拿著壓縮的聲音，有時旁邊有字幕曲目和章節標記。 容器描述每個開始的位置、運行時間以及使用編解碼器的功能，這幾乎就是它所做的。
MP4 中的音流幾乎總是 AAC。 這就是 iPhone 生產的產品，Mac 螢幕錄影會產生什麼，Quicktime Export 生產什麼，無人機生產什麼，以及每個寫 MP4 或 MOV 的相機製作了大約 15 年的時間。 也有例外，主要是舊檔案，內有 MP4 包裝器內有 MP3 音訊，以及帶有未壓縮 PCM 的專業格式，但 AAC 是壓倒性的預設。
這是您擁有的任何文件都可以檢查的。 ffprobe 會在一行中告訴你，大多數視訊播放器中的檔案檢查器也會。 在我為本指南建立的測試剪輯上，音訊串流報告為 aac, 44100 Hz, stereo, 128158 bit/s，這是普通的相機級錄音。
有用的後果是下一節的後果。 一旦您知道該串流是 AAC，您就知道 M4A 可以在不觸摸它的情況下保持它。
為什麼音訊可以在不轉換的情況下出來？
因為 M4A 是同一個容器，視訊部分被遺漏了。
MP4 和 M4A 都是 ISO 基礎媒體檔案格式的設定檔，該結構標準化為 ISO/IEC 14496-12，並由 MP4、M4A、M4V、MOV 和其他少數人共享。 它源自於蘋果的快速時間格式，其 盒子佈局仍完整記錄 並將其讀為 MP4 的描述，因為它幾乎是 MP4 的描述。 框的佈局方式相同，範例表的工作方式相同，寫入一個的 AAC 軌道是字節的位元組，而寫入另一個的軌道是位元組。 擴充功能不同，因此作業系統知道是否要開啟播放器視窗，這就是擴充功能的大部分。
因此，將 MP4 中的音訊提取到 M4A 中並不是轉換。 這是一個複合物：音訊樣本從一個容器中讀取並寫入另一個容器，並且在任何時候都不涉及解碼器或編碼器。 沒有解釋任何內容，因此不能降級。
這與導致視訊方面更大的誤解的區別相同，涵蓋 影片格式指南: 更換包裝紙接近免費，改變內部的壓縮不是。 音訊提取是免費選項也是正確的選項，這比它應該的要少。
在 FFMPEG 術語中，整個操作是四個參數：
ffmpeg -i recording.mp4 -vn -acodec copy recording.m4a
-vn 刪除視訊串流。 不管它，FFMPEG 會嘗試將圖片帶入一個無處可放的容器，這會產生一個 M4A，你的音樂播放器拒絕打開。 -acodec copy 是使它無損的部分：它告訴 FFMPEG 將樣本傳遞給樣本，而不是將它們交給編碼器。
你怎麼知道副本真的沒有丟失？
因為您可以在前後對流進行散列，並且兩個雜湊匹配。
我建立了一個 60 秒的測試檔案，1280x720 H.264 影片，配備 128 Kbps 立體聲 AAC 軌道，總計 19 MB。 然後我將視訊內部的音訊串流散列，複製出音訊，然後再次對其進行雜湊：
$ ffmpeg -i src.mp4 -vn -c:a copy -f md5 -
MD5=650032f86f01780991c64c30bd02f71b
$ ffmpeg -i src.mp4 -vn -acodec copy out.m4a
real 0.04
$ ffmpeg -i out.m4a -c:a copy -f md5 -
MD5=650032f86f01780991c64c30bd02f71b
相同的摘要，因此 M4A 中的壓縮音訊資料是來自影片的壓縮音訊資料，沒有改變。 提取的檔案為 950 KB，整個操作需要 0.04 秒，大約是讀取 SSD 19 MB 所需的時間。
該測試值得在您自己的文件上運行，而不是接受信任，因為它是分辨真實副本與聲稱為 1 的轉換的唯一方法。 如果這兩個雜湊不同，則重新編碼您的音訊，同時告訴您沒有。
選擇 MP3 代替您付出什麼代價？
第二代有損壓縮，加上更大的檔案。
AAC 和 MP3 都透過丟棄精神聲學模型預測您聽不到的內容來工作，他們不同意那是什麼。 他們將訊號分成不同數量的波段，他們以不同的方式進行遮蔽建模，並以不同的方式處理突然的瞬變。 因此，當 MP3 編碼器交給 AAC 檔案的解碼輸出時，它無法判斷哪些部分來自麥克風，哪些部分來自麥克風。 它花費了雙方來保護兩者，並丟掉了一些在第一次通過中倖存下來的東西。
這是通過每條路徑的相同 60 秒剪輯：
| 輸出 | 它是如何製作的？ | 尺寸 | 時間 | 進一步損失 |
|---|---|---|---|---|
| m4a | aac 流複製 | 972,706 位元組 | 0.04 秒 | 沒有，雜湊同一 |
| mp3 192 kbps | 解碼，用跛腳重新編碼 | 1,441,479 位元組 | 0.36 秒 | 是的，第二代 |
| 揮動 | 解碼為 16 位元 PCM | 10,584,142 位元組 | 0.05 秒 | 沒有添加，沒有撤銷 |
MP3 比 M4A 大 48%，同時保持音訊更有損壞的編碼器。 沒有設定可以避免這種情況，因為遺失在解碼和重新編碼本身，而不是在位元率中。
這些都沒有使 MP3 錯。 2009 年的汽車音響、廉價的錄音機、帶有 USB 連接埠和數量驚人的廣播軟體的健身跑步機將讀取 MP3 而不是其他任何東西。 當那是目的地時，代損失就是玩文件的價格，而對語音來說是一個很小的代價。 關鍵是要故意支付，而不是因為工具為您挑選了 MP3。
較高的 MP3 位元率會使擷取更好嗎？
它使 MP3 成為損壞音訊的更忠實副本，這與更好的情況不同。
我用寬頻來源測試了這個，因為純音對編解碼器來說很容易，什麼也沒告訴你。 測試片段是 30 秒的粉紅色噪音和低正弦混合，編碼為 128 kbps AAC，這大致就是真正音樂在編碼器上的硬度。 然後我將 AAC 解碼為 PCM 以用作參考，以兩個位元率將其編碼為 MP3，並測量每個與參考的信號與失真比率：
| mp3 位元率 | 尺寸為 30 秒 | SDR 反對 AAC 來源 |
|---|---|---|
| 192 kbps | 705 千克 | 26.7 分貝 |
| 320 kbps | 1.1 兆位元組 | 42.3 分貝 |
320 kbps 檔案是 AAC 音訊的更近的再現，大約 15 分貝。它不是更接近原始錄音的再現，因為 AAC 已經丟棄了它，沒有編碼器可以放回它。 額外的 400 KB 購買了第一個編碼器輸出的更忠實副本，包括人工製品。
所以規則從 音頻轉換器指南 持有，背後有更尖銳的理由。 匹配或略微削弱來源位元率是合理的範圍。 遠高於它正在花費儲存以保存錄音中沒有的細節，而遠低於它會丟棄它的第二個幫助。
如果忠於原版是您關心的，那麼答案就不是比特率。 它是 M4A 副本，沒有比特率決定。
WAV 什麼時候是正確的答案？
當下游某事需要 PCM 時，這比人們預期的要多。
音訊編輯器更喜歡它，因為它不需要解碼，並且可以按樣本編輯樣本。 轉錄服務和語音模型經常需要它，接受壓縮音訊的那些通常無論如何都會將其解碼為內部 PCM。 強制對準工具、聲學分析軟體和任何訊號處理都從 PCM 開始。
WAV 沒有增加進一步的損失，儘管它無法撤銷來源已經丟棄的東西。 由 128 Kbps AAC 音軌製成的 WAV 仍然缺少 AAC 所缺少的每一個細節。 它是損壞音訊的忠實容器，這正是您想要的下一步分析而不是聆聽時想要的。
在這一點上，測量的結果令人放心。 我提取的 WAV 與原始音訊的直接解碼相同，相同的 MD5，因此提取並沒有添加任何自己的內容。 成本是大小，下一節介紹。
16 位元 44.1 kHz 立體聲是明智的預設，也是提取器寫的。 它是 CD 規格，它是普遍可讀的，從一開始就有損的來源編寫 24 位元 PCM 沒有任何好處。
文件會有多大？
可以預見的是，這是有用的部分。
音訊大小是比特率乘以持續時間，不依賴內容，因此與視訊不同，它可以在工作開始之前告訴您，而不是事後猜測。
| 格式 | 每分鐘，立體聲 | 一小時 |
|---|---|---|
| M4A 從 128 kbps 來源複製 | 0.95 兆位元組 | 57 兆位元組 |
| mp3 192 kbps | 1.4 兆位元組 | 84 兆位元組 |
| mp3 128 kbps | 0.96 兆位元組 | 58 兆位元組 |
| WAV 16 位元 44.1 kHz | 10.1 兆位元組 | 606 兆位元組 |
WAV 行是讓人們感到驚訝的那一排。 每分鐘 10.1 MB 是上述測試中的測量數字，它直接從算術中得出：44,100 個樣本，每個樣本，兩個位元組，兩個通道。 WAV 中的一小時講座音訊是一個 600 MB 的檔案，它比它出來的許多影片都要大，而且比某些服務將接受的上傳更大。
這也是為什麼提取器在運行之前顯示一個估計值。 提取到 WAV 的一小時錄音是一件合理的事情，也是一件不合理的事情。
為什麼 WebM 拒絕將其音訊複製到 M4A 中？
因為裡面的編解碼器是 MPEG-4 容器無法攜帶的，而且工具是誠實的，而不是默默地重新編碼。
WebM 擁有 Opus 或 Vorbis Audio，而不是 AAC。 就標準 Muxers 而言，兩者都不屬於 M4A，因此複製路徑不可用。 ffmpeg 說得很清楚：
[ipod @ 0x75bd019180] Could not find tag for codec opus in stream #0,
codec not currently supported in container
[out#0/ipod] Could not write header (incorrect codec parameters ?)
有一個已發布的規範 將 Opus 封裝在 ISO 基礎媒體容器中，所以這是一個工具和回放現實，而不是理論上的不可能。 在實踐中，您不會將文件交給一個充滿 Opus 的 M4A，因此有用的答案是重新編碼。 在相同的測試內容上，在 20 秒的音訊中花費 0.32 秒並產生 473 KB 檔案，這是一代遺失，也是唯一可用的選項。
相同的邏輯決定了所有其他來源。 MP4、MOV、M4V 和 M4A 可以複製他們的 AAC。 WebM、MKV 與 Opus 或 Vorbis 以及任何從 MPEG-4 系列外部承載編解碼器的東西都不能，提取器說您在它開始之前而不是之後處於哪個情況。
為什麼持續時間不完全匹配？
因為 AAC 和 MP3 都對輸出進行了填充，而這兩個容器處理填充的處理方式不同。 是打破無間隙播放的細節，在測試數字中清楚地顯示出來。
來源音訊剛好是 60 秒，2,646,000 個樣本，頻率為 44.1 kHz。 提取的 M4A 報告的持續時間剛好是 60.000000 秒。 提取的 WAV 和 MP3 都報告了 60.000363 秒，比 16 個樣本長了 16 個。
這 16 個樣本是編碼器延遲。 AAC 在 1024 個樣本幀中工作，因此 60 秒的錄音不會均勻分割，編碼器會填充末端。 M4A 使用編輯清單隱藏這一點，容器中的一個小表格說明解碼輸出的哪一部分是真實記錄。 解碼 M4A 後，您會取回 2,646,016 個樣本，這是 WAV 的額外 0.36 毫秒的來源。
MP3 沒有編輯清單，因為格式早於這個想法。 它的是 LAME 資訊標籤，這是第一個框架中的供應商區塊，記錄每端要丟棄多少個樣本。 那個 字段佈局由位元組由位元組記錄，以及編碼器延遲和端板共用位元組 0xB1 到 0xB3 作為兩個 12 位元值。 解碼後，MP3 以 2,646,016 個樣本的形式返回，與 WAV 完全匹配，因此標籤在這裡起作用。 忽略它的播放器，或無法編碼的編碼器，是連續專輯曲目之間的可聽點擊聲來源。
這些都不適合講座或播客。 對於現場專輯或 DJ 混音來說，這很重要，這就是為什麼複製路徑值得喜歡時：不涉及編碼器，因此沒有新的填充物可供考慮。
M4a 是否在任何地方播放 mp3 播放？
接近它，在你提交之前有一小部分值得了解的例外。
這十年的一切讓這十年的一切都在玩 M4A。iOS 和 Android 都原生地做，每個桌面作業系統都能做到，每個瀏覽器都可以，Spotify、VLC 和 Plex 以及你擁有的任何手機上的庫存音樂應用程式。 該格式已有 20 年歷史，並且一直是地球上最受歡迎的手機的預設輸出。
例外情況聚集在兩個地方。 第一個是舊的汽車音響和獨立硬體，尤其是 2012 年之前的主機，其中一個裝滿 M4A 檔案的 USB 貼圖讀成空。 第二個是接受音訊上傳和透過擴展而不是內容驗證的軟體，它拒絕在多年前寫的清單上並且從未重新訪問過的 M4A。 轉錄服務在這裡是一個普通的罪犯，這就是記者 音頻轉換器指南 最後得到了她的服務不會佔用的四個小時的文件。
一種合理的方法：先提取到 M4A，因為它是即時無損的，並保持它作為主人。 如果目的地拒絕它，請將該 M4A 轉換為 MP3。 然後，您已經支付了一代損失，而不是讓有損副本成為您唯一的副本。
提取需要多長時間，是什麼決定的？
讀取文件，然後是是否涉及編碼器。
複製路徑由磁碟和記憶體速度而不是處理來限制。 19 MB 檔案的 0.04 秒不是正在處理的音訊，而是正在讀取的檔案和正在寫入的新容器。 擴大它，在一兩秒鐘內發布了 40 分鐘的數百兆位元講座錄音，幾乎所有這些都是瀏覽器將文件讀入標籤。
編碼路徑由編碼器限制。 跛行在這台機器上花費了 0.36 秒的立體聲音訊 60 秒，大約比實時快 165 倍，所以一小時的音訊大約是 20 秒的工作時間。 從類似的 WebM 重新編碼 AAC。 這些速度足夠快，以至於進度條主要是為了誠實而不是必要。
有一件事確實主導了其他一切，它不是音訊。 將來源影片載入到頁面中是大檔案的緩慢步驟，因為整個檔案會進入 Tab 記憶體。 這就是 500 MB 上限的原因：除此之外，選項卡開始以比規定的限制更難解釋的方式失敗。 如果您正在使用比這更大的文件，請先使用 視訊修剪器 通常比對抗極限更快，而且 修剪指南 涵蓋了為什麼這種切割幾乎是免費的。
當影片有多個音軌時會發生什麼？
一首曲目出來，為您選擇，其他曲目則不加評論地刪除。 這是值得知道的，因為這是一個安靜的失敗，而不是一個響亮的失敗。
我用一個檔案對其進行了測試，該文件包含兩個音訊串流、一個 128 kbps 的立體聲軌道和一個 64 kbps 的單聲道，這大致是帶有相機麥克風和單獨的翻領麥克風的錄音的形狀。 提取產生一個單一的流，128 kbps 立體聲一，950 kb，沒有提到第二個軌道存在。
選擇不是隨機的。ffmpeg's 記錄的流選擇規則 選擇它判斷的最佳流，對於音頻來說，這意味著最高的頻道計數，所以你通常會得到你想要的。 但是，如果安靜的單聲道是採訪音頻，而立體聲是來自相機的室內噪音，那麼你就會得到錯誤的東西，沒有什麼能告訴你。
多軌檔案在專業工作流程之外並不常見，手機或螢幕錄影機幾乎沒有一個音訊串流。 如果您正在使用真實拍攝的鏡頭，請在提取之前查看流列表，並期望直接使用 FFMPEG 並使用明確 -map 0:a:1 當您需要第二條軌道時。
您應該提取音訊還是轉換整個影片？
提取，如果你想要的是聲音。 這兩種操作不是替代方案，人們會定期找錯。
將影片轉換為 MP3 是一個出現在每月數百萬次搜尋中的短語，並描述了無人想要的操作。 這意味著解碼和丟棄圖片，解碼音訊並重新編碼，這是一項艱鉅的工作，可以達到已經存在的更糟糕的版本。 那個 視訊轉換器 存在於您想要最後一個影片的格式中，以某種形式播放。 當您想要音訊時，提取就是操作，複製路徑意味著它也是便宜的。
決策表很短：
| 你想要什麼 | 使用 | 成本 |
|---|---|---|
| 配樂作為文件 | 提取到 m4a | 沒什麼，流複製 |
| 編輯或抄寫員的配樂 | 提取到 wav | 僅尺寸 |
| 舊硬體上的配樂 | 提取到 mp3 | 一代 |
| 較小的影片，包括圖片 | 視訊壓縮機 | 取決於 CRF，請參閱 壓縮指南 |
| 以播放格式的相同影片 | 視訊轉換器 | 通常是remux，所以什麼都沒有 |
所有五行的模式都是值得一提的：詢問操作是否需要重新編碼，並且更喜歡不需要的。
在瀏覽器中執行此操作會發生什麼變化？
錄音去哪裡，音頻通常是整個問題。
提取器運行編譯為 WebAssembly 頁面內的 FFMPEG。 影片從您的磁碟讀取到標籤內存，音訊串流在那裡被拉出，結果作為下載傳回。 沒有請求攜帶文件，伺服器上沒有排隊，也沒有任何副本存在於任何人忘記刪除的地方。
人們提取的音訊主要是讓這件事變得如此。 記錄的會議、講座、訪談、諮詢、與律師或醫生的電話、配音備忘錄，其中包含您不會發布的內容。 傳統的選擇是將錄音上傳到您一無所知的網站，以換取在複製路徑上是容器的操作，請在一秒鐘內重寫您自己的機器完成。
交易是 500 MB 上限和一次文件工作流程，因為瀏覽器標籤的記憶體比伺服器少，也沒有隊列。 對於單個錄音，這幾乎總是用於，這是您無法達到的限制，也是您無法獲得任何其他方式的隱私保證。
