Iemand vroeg me om het geluid van een 40 minuten durende college-opname te halen, zodat het een telefoon kon maken voor het woon-werkverkeer. Ik deed eerst het voor de hand liggende ding, namelijk het converteren naar mp3, en het duurde een paar minuten en produceerde een bestand dat iets groter was dan de audio die al in de video zat. Daarna deed ik wat ik eerst had moeten doen en in plaats daarvan de track uitkopen. Het duurde minder dan een seconde, het bestand was kleiner en de audio was een beetje identiek aan wat de recorder heeft vastgelegd. De tweede methode is geen truc of een snelkoppeling. Het is waar het bestandsformaat voor is ontworpen, en bijna elke converter die deze vraag beantwoordt, negeert het.
tl;dr: Een MP4 of MOV draagt meestal AAC-audio en een M4A is diezelfde AAC in een audiocontainer uit dezelfde familie, zodat de track direct kan worden gekopieerd zonder decodering en zonder verlies. Gemeten op een testclip van 60 seconden hier: de kopie eindigde in 0,04 seconden en de geëxtraheerde audiostroom had dezelfde MD5 als de stream in de video. Het coderen van dezelfde audio naar MP3 met 192 kbps duurde 0,36 seconden, produceerde een bestand dat 48% groter was en ging door een tweede ronde van lossy compressie die het niet nodig had. Kies M4A, tenzij iets stroomafwaarts het weigert, kies WAV wanneer een editor of een transcribent PCM wil, en kies MP3 alleen voor een apparaat dat niets anders leest. de audio-extractor Doet ze alle drie op het tabblad Browser, dus een opgenomen vergadering verlaat de machine nooit.
Wat zit er in een mp4's audiotrack?
Een MP4 is een container, wat betekent dat het een archiveringssysteem is in plaats van een formaat. Binnenin zijn afzonderlijke streams: een met gecomprimeerde afbeeldingen, een met gecomprimeerd geluid, soms ondertiteltracks en hoofdstukmarkeringen ernaast. De container beschrijft waar elk begint, hoe lang het loopt en welke codec is gebruikt, en dat is bijna alles wat het doet.
De geluidsstroom in een MP4 is bijna altijd AAC. Dat is wat een iPhone produceert, wat een Mac-schermopname produceert, wat een QuickTime-export produceert, wat een drone produceert en wat elke camera die MP4 of MOV schrijft al ongeveer vijftien jaar heeft geproduceerd. Er zijn uitzonderingen, meestal oudere bestanden met mp3-audio in een MP4-wrapper en professionele formaten met ongecomprimeerde PCM, maar AAC is de overweldigende standaard.
Dit is te controleren op elk bestand dat u heeft. ffprobe zal het je in één regel vertellen, en dat geldt ook voor de bestandsinspecteur in de meeste videospelers. Op de testclip die ik voor deze handleiding heb gemaakt, meldt de audiostream dat aac, 44100 Hz, stereo, 128158 bit/s, wat een gewone camera-opname is.
Het nuttige gevolg is dat in de volgende sectie. Als je eenmaal weet dat de stream AAC is, weet je dat een M4A hem kan vasthouden zonder hem aan te raken.
Waarom kan de audio uitkomen zonder te worden geconverteerd?
Omdat M4A dezelfde container is met het videogedeelte weggelaten.
Zowel MP4 als M4A zijn profielen van het ISO-basismediabestandsformaat, de structuur gestandaardiseerd als ISO/IEC 14496-12 en gedeeld door MP4, M4A, M4V, MOV en een handvol andere. Het is voortgekomen uit het QuickTime-formaat van Apple, waarvan Boxlay-out is nog steeds volledig gedocumenteerd en leest als een beschrijving van MP4 omdat het bijna één is. De dozen zijn op dezelfde manier ingedeeld, de voorbeeldtabellen werken op dezelfde manier en een AAC-track in de ene is byte voor byte hetzelfde nummer dat in de andere is geschreven. De extensie verschilt zodat een besturingssysteem weet of een spelervenster moet openen, en dat is het meeste waar de extensie voor is.
Dus audio extraheren van een MP4 naar een M4A is geen conversie. Het is een Remux: de audiosamples worden uit de ene container uitgelezen en in een andere geschreven, en er is op geen enkel moment een decoder of encoder bij betrokken. Niets wordt geïnterpreteerd, dus niets kan worden gedegradeerd.
Dit is hetzelfde onderscheid dat het grotere misverstand aan de videokant veroorzaakt, bedekt met De video-indelingsgids: Het wijzigen van een wrapper is bijna gratis, het wijzigen van de compressie erin is dat niet. Audio-extractie is het geval waarin de gratis optie ook de juiste is, wat zeldzamer is dan het zou moeten zijn.
In FFMPEG-termen is de hele bewerking vier argumenten:
ffmpeg -i recording.mp4 -vn -acodec copy recording.m4a
-vn Laat de videostream vallen. Laat het weg en FFmpeg probeert de foto in een container te dragen die nergens kan worden geplaatst, waardoor een M4A wordt geproduceerd die je muziekspeler weigert te openen. -acodec copy is het deel dat het verliesloos maakt: het vertelt FFmpeg om de monsters door te geven in plaats van ze aan een encoder te geven.
Hoe weet je dat de kopie echt niets heeft verloren?
Omdat je de stream voor en na kunt hashen, en de twee hashes matchen.
Ik heb een testbestand van 60 seconden gebouwd, 1280x720 H.264 video met een 128 kbps stereo AAC-track, in totaal 19 MB. Daarna heb ik de audiostream in de video gehasht, de audio gekopieerd en opnieuw gehasht:
$ 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
Dezelfde samenvatting, dus de gecomprimeerde audiogegevens in de M4A zijn de gecomprimeerde audiogegevens van de video, zonder dat één bit is gewijzigd. Het geëxtraheerde bestand was 950 kb en de hele bewerking duurde 0,04 seconden, wat ongeveer de tijd is die nodig is om 19 MB van een SSD te lezen.
Die test is het waard om op je eigen bestand uit te voeren in plaats van vertrouwen aan te nemen, omdat het de enige manier is om een echte kopie te onderscheiden van een conversie die beweert er een te zijn. Als de twee hashes verschillen, heeft iets je audio opnieuw gecodeerd terwijl je je vertelde dat dit niet het geval was.
Wat kost het kiezen van MP3 in plaats daarvan je?
Een tweede generatie lossy compressie, plus een groter bestand.
AAC en MP3 werken beide door weg te gooien wat een psychoakoestisch model voorspelt dat je niet kunt horen, en ze zijn het niet eens over wat dat is. Ze splitsen het signaal in verschillende aantallen banden, ze modelleren anders maskeren en ze gaan anders om met plotselinge transiënten. Dus wanneer een MP3-encoder de gedecodeerde uitvoer van een AAC-bestand krijgt, kan hij niet zeggen welke onderdelen uit de microfoon kwamen en welke de eerste encoder achterliet. Het besteedt stukjes aan het behoud van beide, en gooit een deel van wat de eerste pass heeft overleefd weg.
Hier is dezelfde clip van 60 seconden door elk pad:
| prestatie | Hoe het werd gemaakt | Maat | keer | verder verlies |
|---|---|---|---|---|
| M4A | AAC-stream gekopieerd | 972.706 bytes | 0,04 s | Geen, hasj-identiek |
| mp3 192 kbps | Gedecodeerd, opnieuw gecodeerd met lame | 1.441.479 bytes | 0,36 s | Ja, tweede generatie |
| golvend | Gedecodeerd tot 16-bits PCM | 10.584.142 bytes | 0,05 s | Geen toegevoegd, geen ongedaan gemaakt |
De MP3 is 48% groter dan de M4A terwijl hij audio vasthoudt die nog een losse encoder heeft meegemaakt. Er is geen instelling die dit vermijdt, omdat het verlies in de decodering zit en opnieuw codeert in plaats van in de bitsnelheid.
Geen van alle maakt mp3 verkeerd. Een autoradio uit 2009, een goedkope voicerecorder, een sportschoolloopband met een USB-poort en een verrassende hoeveelheid broadcastsoftware, zal mp3 lezen en niets anders. Wanneer dat de bestemming is, is het generatieverlies de prijs van het afspelen van het bestand, en het is een kleine prijs voor spraak. Het punt is om het bewust te betalen in plaats van omdat een tool mp3 voor je heeft gekozen.
Maakt een hogere mp3-bitrate de extractie beter?
Het maakt de MP3 een meer getrouwe kopie van de beschadigde audio, wat niet hetzelfde is als beter.
Ik heb dit getest met een breedbandbron, omdat pure tonen gemakkelijk zijn voor een codec en je niets vertellen. De testclip was 30 seconden roze ruis vermengd met een lage sinus, gecodeerd tot 128 kbps AAC, wat ongeveer is hoe hard echt muziek is op een encoder. Vervolgens decodeerde ik die AAC naar PCM om als referentie te gebruiken, codeerde het op MP3 met twee bitsnelheden, en mat het signaal-vervormingsverhouding van elk van elk af tegen de referentie:
| mp3-bitrate | Maat voor 30 s | SDR tegen de AAC-bron |
|---|---|---|
| 192 kbps | 705 kb | 26,7 dB |
| 320 kbps | 1.1 MB | 42,3 dB |
Het 320 kbps-bestand is een veel dichterbije weergave van de AAC-audio, met ongeveer 15 dB. Wat het niet is, is een nauwere weergave van de originele opname, omdat de AAC dat al heeft weggegooid en geen encoder het terug kan plaatsen. De extra 400 kb kocht een meer getrouwe kopie van de eerste encoder-output, inclusief artefacten.
Dus de regel van De audio-omzettergids houdt, met een scherpere reden erachter. Het matchen of licht ondergraven van de bronbittrate is het verstandige bereik. Het gaat goed boven het uitgeven van opslag om details te behouden die niet in de opname zitten, en als je er goed onder gaat, gooit het een tweede portie weg van wat er is.
Als trouw aan het origineel is waar je om geeft, is het antwoord geen bitrate. Het is de M4A-kopie, die geen bitrate-beslissing moet nemen.
Wanneer is WAV het juiste antwoord?
Wanneer iets stroomafwaarts wil PCM, wat vaker gebeurt dan mensen verwachten.
Audio-editors geven er de voorkeur aan omdat het geen decodering nodig heeft en kan worden bewerkt als voorbeeld per voorbeeld. Transcriptiediensten en spraakmodellen eisen vaak het, en degenen die gecomprimeerde audio accepteren, decoderen het meestal toch intern naar PCM. Gedwongen uitlijningstools, akoestische analysesoftware en alles wat signaalverwerking doet, beginnen allemaal vanaf PCM.
WAV voegt geen verder verlies toe, hoewel het niet ongedaan kan maken wat de bron al heeft weggegooid. Een wav gemaakt van een 128 kbps AAC-track heeft nog steeds elk ontbrekend detail dat de AAC miste. Het is een getrouwe container voor beschadigde audio, en dat is precies wat je wilt als de volgende stap analyse is in plaats van luisteren.
Het gemeten resultaat is geruststellend op dit punt. De WAV die ik heb geëxtraheerd, was een beetje identiek aan een directe decodering van de bronaudio, dezelfde MD5, dus de extractie voegde niets van zichzelf toe. De kosten zijn de grootte, die in de volgende sectie dekt.
16-bits 44,1 kHz stereo is de verstandige standaard en wat de extractor schrijft. Het is CD-specificatie, het is universeel leesbaar en er wordt niets gewonnen door 24-bits PCM te schrijven van een bron die in het begin verloren was.
Hoe groot wordt het bestand?
Voorspelbaar, wat het nuttige deel is.
Audiogrootte is de duur van de bitrate-tijden, zonder afhankelijkheid van inhoud, dus in tegenstelling tot video kan het u worden verteld voordat het werk begint in plaats van achteraf te worden geraden.
| formaat | per minuut, stereo | een uur |
|---|---|---|
| M4A gekopieerd van een 128 kbps bron | 0,95 MB | 57 MB |
| mp3 192 kbps | 1,4 MB | 84 MB |
| mp3 128 kbps | 0,96 MB | 58 MB |
| WAV 16-bits 44,1 kHz | 10,1 MB | 606 MB |
De WAV-rij is degene die mensen verrast. 10,1 MB per minuut is een gemeten figuur uit de bovenstaande test, en het volgt rechtstreeks uit de rekenkunde: 44.100 monsters per tweede, twee bytes per monster, twee kanalen. Een uur lang college-audio in WAV is een bestand van 600 MB, dat groter is dan veel van de video's waaruit het is gekomen en groter dan sommige services als upload zullen accepteren.
Daarom laat de afzuigkap ook een schatting zien voordat deze loopt. Een opname van een uur die naar WAV is geëxtraheerd, is redelijk om te willen en een onredelijk iets om verrast door te worden.
Waarom weigert een WebM zijn audio te kopiëren naar een M4A?
Omdat de codec erin een is die de MPEG-4-container niet zal dragen, en de tool daar eerlijk over is in plaats van stil te hercoderen.
Een WebM houdt Opus of Vorbis-audio vast, niet AAC. Geen van beide behoort tot de standaard muxers in een M4A, dus het kopieerpad is niet beschikbaar. ffmpeg zegt het zo duidelijk:
[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 ?)
Er is een gepubliceerde specificatie voor Opus inkapselen in een ISO-basismediacontainer, dus dit is een tooling en playback-realiteit in plaats van een theoretische onmogelijkheid. In de praktijk zou niets je het bestand overhandigen om een M4A vol opus af te spelen, dus het nuttige antwoord is om opnieuw te coderen. Op dezelfde testinhoud die 20 seconden audio 0,32 seconden duurde en een bestand van 473 kb produceerde, wat een generatie verlies is en de enige beschikbare optie.
Dezelfde logica bepaalt elke andere bron. MP4, MOV, M4V en M4A kunnen hun AAC laten kopiëren. WebM, MKV met Opus of Vorbis, en alles wat een codec van buiten de MPEG-4-familie draagt, kan dat niet, en de afzuigkap zegt in welk geval u zich bevindt voordat het begint in plaats van daarna.
Waarom komen de duur niet precies overeen?
Omdat AAC en MP3 allebei hun output inkussen, en de twee containers die opvulling anders verwerken. Het is het detail dat het afspelen van gaples doorbreekt en het verschijnt duidelijk in de testnummers.
De bronaudio was precies 60 seconden, 2.646.000 samples bij 44,1 kHz. De geëxtraheerde M4A meldt een duur van precies 60.000000 seconden. De geëxtraheerde WAV en MP3 rapporteren beide 60.000363 seconden, wat 16 monsters langer zijn.
Die 16 monsters zijn encodervertraging. AAC werkt in 1024 voorbeeldframes, dus een opname van 60 seconden deelt niet gelijkmatig en de encoder vult het einde. De M4A verbergt dit met behulp van een bewerkingslijst, een kleine tabel in de container die zegt welk deel van de gedecodeerde uitvoer de echte opname is. Decodeer de M4A en je krijgt de gewatteerde 2.646.016 monsters terug, waar de WAV extra 0,36 milliseconden vandaan komen.
MP3 heeft geen bewerkingslijst, omdat het formaat dateert van vóór het idee. Wat het in plaats daarvan heeft, is de lame informatietag, een leveranciersblok in het eerste frame dat vastlegt hoeveel monsters aan elk uiteinde moeten worden weggegooid. de Veldlay-out wordt gedocumenteerd byte per byte, en de encodervertraging en eindopvulling delen bytes 0xB1 tot 0xB3 als twee 12-bits waarden. Gedecodeerd, kwam de MP3 terug op 2.646.016 monsters, precies overeenkomend met de WAV, dus de tag deed zijn werk hier. Een speler die het negeert, of een encoder die het niet schrijft, is waar de hoorbare klik tussen nummers van een doorlopend album vandaan komt.
Dit alles doet er niet toe voor een lezing of een podcast. Het is erg belangrijk voor een live album of een DJ-mix, en het is de reden waarom het kopieerpad de moeite waard is om het te verkiezen wanneer het beschikbaar is: er is geen encoder bij betrokken, dus er is geen nieuwe opvulling om rekening mee te houden.
Speelt m4a overal mp3-speelt?
Dichtbij, met een korte lijst met uitzonderingen die het waard zijn om te weten voordat u zich vastlegt.
Alles wat dit decennium maakte, speelt M4A. iOS en Android doen het allebei native, elk desktopbesturingssysteem doet dat, elke browser doet dat, Spotify en VLC en Plex en de stockmuziek-app op welke telefoon je ook hebt. Het formaat is twintig jaar oud en is voor de meesten van hen de standaarduitvoer van de meest populaire telefoon op aarde.
De uitzonderingen clusteren op twee plaatsen. De eerste zijn oudere autoradio's en standalone hardware, met name head-units van vóór ongeveer 2012, waar een USB-stick vol M4A-bestanden als leeg leest. De tweede is software die audio-uploads accepteert en valideert op extensie in plaats van door inhoud, die een M4A op een lijst die jaren geleden is geschreven en nooit opnieuw is bekeken, weigert. Transcriptiediensten waren hier een veelvoorkomende overtreder, en dat is hoe de journalist in De audio-omzettergids Uiteindelijk vier uur aan bestanden die haar dienst niet zou duren.
Een redelijke benadering: eerst naar M4A uitpakken, omdat het direct en zonder verlies is, en het als de meester te houden. Als de bestemming het weigert, converteer die M4A eenmaal naar MP3. U heeft dan betaald voor één generatie verlies in plaats van de lossy kopie uw enige exemplaar te maken.
Hoe lang duurt een extractie en wat bepaalt dat?
het bestand meestal lezen en dan of er een encoder bij betrokken is.
Het kopieerpad wordt begrensd door schijf- en geheugensnelheid in plaats van door verwerking. 0,04 seconden voor een 19 MB-bestand is niet de audio waaraan wordt gewerkt, het is het bestand dat wordt gelezen en een nieuwe container wordt geschreven. Als je dat opschaelt, komt er in een seconde of twee een lezing van 40 minuten durende lezing van een paar honderd megabytes uit, en dat is bijna allemaal de browser die het bestand op het tabblad leest.
De coderingspaden worden begrensd door de encoder. Lame nam 0,36 seconden voor 60 seconden stereogeluid op deze machine, wat ongeveer 165 keer sneller is dan realtime, dus een uur audio is ongeveer 20 seconden werk. AAC-codering van een WebM die op dezelfde manier is gemeten. Deze zijn snel genoeg dat de voortgangsbalk er meestal voor eerlijkheid in plaats van noodzaak is.
Eén ding domineert al het andere, en het is niet het geluid. Het laden van de bronvideo op de pagina is de langzame stap voor een groot bestand, omdat het hele bestand in het tabbladgeheugen gaat. Dat is de reden voor de 500 MB limiet: daarbuiten begint een tabblad te falen op manieren die moeilijker uit te leggen zijn dan een aangegeven limiet. Als u met een groter bestand werkt, trimt u het eerst met de Videomaaier is meestal sneller dan het bestrijden van de limiet, en De trimgids Dekt waarom die snit ook bijna gratis is.
Wat gebeurt er als een video meer dan één audiotrack heeft?
Eén nummer komt uit, voor jou gekozen, en de andere worden zonder commentaar gedropt. Dit is het weten waard, omdat het een stille mislukking is in plaats van een luide.
Ik heb het getest met een bestand met twee audiostreams, een stereotrack van 128 kbps en een mono-een van 64 kbps, wat ruwweg de vorm is van een opname met een cameramicrofoon en een afzonderlijke reversmicrofoon. Extractering produceerde een enkele stroom, de 128 kbps stereo One, 950 kb, zonder vermelding dat er een tweede nummer had bestaan.
De selectie is niet willekeurig. Gedocumenteerde streamselectieregels Kies de stream die het het beste beoordeelt, wat voor audio het hoogste aantal kanalen betekent, dus je krijgt meestal degene die je wilde. Maar als de stille mono-track de interviewaudio was en de stereo kamerruis van de camera, dan krijg je het verkeerde en niets vertelt je.
Multi-track-bestanden zijn ongebruikelijk buiten professionele workflows, en bijna niets van een telefoon of een schermrecorder heeft meer dan één audiostream. Als u met beeldmateriaal van een echte opname werkt, controleer dan de streamlijst voordat u deze uittrekt en verwacht FFMPEG rechtstreeks te gebruiken met een expliciete -map 0:a:1 Wanneer je het tweede nummer nodig hebt.
Moet je de audio uitpakken of de hele video converteren?
Extract, als wat je wilt het geluid is. De twee operaties zijn geen alternatieven en mensen grijpen regelmatig naar de verkeerde.
Het converteren van een video naar mp3 is een zin die in miljoenen zoekopdrachten per maand verschijnt en een operatie beschrijft die niemand wil. Het impliceert het decoderen en weggooien van de foto, het decoderen van de audio en het opnieuw coderen ervan, wat veel werk is om tot een slechtere versie te komen van iets dat er al was. de video-omzetter Bestaat voor het geval dat je aan het einde een video wilt, in een formaat dat iets zal afspelen. Als je audio wilt, is extractie de bewerking, en het kopieerpad betekent dat het ook de goedkope is.
De beslissingstabel is kort:
| Wat je wilt | goed doen | prijs |
|---|---|---|
| De soundtrack als een bestand | Extract naar M4A | niets, stream gekopieerd |
| de soundtrack voor een editor of transcribent | uitpakken naar wav | Alleen formaat |
| De soundtrack op oude hardware | Uitpakken naar mp3 | Een generatie |
| Een kleinere video, foto inbegrepen | videocompressor | hangt af van CRF, zie De compressiegids |
| Dezelfde video in een formaat dat wordt afgespeeld | video-omzetter | Vaak een remux, dus niets |
Het patroon over alle vijf rijen is het patroon dat het waard is om weg te nemen: vraag of de bewerking opnieuw moet worden gecodeerd en geef de voorkeur aan het patroon dat niet het geval is.
Wat verandert dit in de browser?
Waar de opname heen gaat, wat voor audio meestal de hele vraag is.
De afzuigkap draait FFmpeg gecompileerd naar WebAssembly binnen de pagina. De video wordt van je schijf in het tabgeheugen gelezen, de audiostream wordt daar naar buiten gehaald en het resultaat wordt teruggegeven als download. Geen enkel verzoek draagt het bestand, niets staat in de wachtrij op een server en nergens een kopie voor iedereen om te vergeten te verwijderen.
De audio die mensen uitpakken is meestal het soort dat maakt dit. Opgenomen vergaderingen, lezingen, interviews, consultaties, telefoontjes met een advocaat of een arts, stemmemo's met dingen erin die je niet zou posten. Het conventionele alternatief is om de opname te uploaden naar een site waar je niets van af weet, in ruil voor een bewerking die op het kopieerpad een container is, herschrijf je eigen machine in minder dan een seconde.
De handel is de 500 MB limiet en de one-file-a-time workflow, omdat een browsertabblad minder geheugen heeft dan een server en geen wachtrij. Voor een enkele opname, waar dit bijna altijd voor is, is dat een limiet die je niet zult bereiken en een privacygarantie die je niet anders kunt krijgen.
