Meta rolt audiocodec MLow uit naar WhatsApp

Meta is bezig met de uitrol van zijn nieuwe audiocodec Meta Low Bitrate, ofwel MLow, naar WhatsApp. Het is al beschikbaar in Instagram en Messenger. De codec moet het beter mogelijk maken om audiogesprekken te voeren bij slechte internetverbindingen.

Eerder gebruikte Meta de opensourcecodec Opus uit 2012 voor audiogesprekken. De geluidskwaliteit van MLow is echter beter bij een lagere bitrate, beweert Meta. Het bedrijf heeft verschillende audiobestanden gedeeld die het verschil tussen Opus en MLow laten horen.

MLow
Het verschil tussen MLow en Opus bij verschillende bitrates. Bron: Meta

Bij MLow wordt pcm-audio ingevoerd in een encoder, die het signaal vervolgens splitst in twee frequentiebanden: een hoge en een lage. Vervolgens wordt elke band afzonderlijk gecodeerd. Bij de ontvanger worden de banden weer door een encoder geleid om ze te decomprimeren en een gecodeerde payload te genereren.

MLow
Bron: Meta

Meta heeft de codec niet gebaseerd op kunstmatige intelligentie, omdat zoiets meer energie vereist. Daarnaast kunnen oudere toestellen moeilijker omgaan met op AI-gebaseerde codecs. Het bedrijf wijst erop dat 'tientallen miljoenen telefoons' waarmee dagelijks wordt gebeld via WhatsApp, tien jaar of ouder zijn.

Door Loïs Franx

Redacteur

14-06-2024 • 15:04

48

Submitter: japie06

Reacties (48)

Sorteer op:

Weergave:

Volgens mij is dat een audio quality perception getal, en als ik het goed herrinner is 5 niet te onderscheiden.

Efff snel gegoalled, en hier staat dezelfde schaal in
https://listening-test.coresv.net/results.htm

5 inperceprible
4 perceptible, but not annoying
3 slightly annoying
2 annoying
1 very annoying

Dit wordt veel vaker gebrukt tijdens luister tests van codec.
Wat ik mis in het artikel is latency. Kwaliteit is vaak voldoende, maar vertragingen zijn erg irritant.
Ik mis nog de eenheid van verticale as?
De POLQA Mean Opinion Score (MOS) score (zoals er ook boven staat): Wikipedia: Perceptual Objective Listening Quality Analysis
zoals er ook boven staat
Dat is niet hoe je de assen van een grafiek labeled, maar goed...
M.a.w. eenheidsloos
Die mis ik ook, mijn gok was gebruikerservaring op een vijf punten schaal.
Mean Opinion Score,

[Reactie gewijzigd door hcQd op 22 juli 2024 22:03]

Even zoeken naar AI gebaseerde codecs levert wel interessante resultaten. Ik zie bijvoorbeeld van Meta zelf: https://github.com/facebo...ncodec?tab=readme-ov-file

Vraag mij af waarom ze dan niet meerdere technieken combineren. Ik zou best wel wat accuduur willen inleveren als dat betekend dat whatsapp bellen (of via video) makkelijker gaat -in bepaalde situaties- bij slecht bereik.
Het moeilijke is dat jij dat wellicht ervoor over hebt en relevante hardware, maar beide kanten moeten de en- en decoding techniek ondersteunen.

Het loont niet als een andere methode wel door (bij wijze van) 90% van de toestellen werkt.
Zo kun je wel blijven downgraden. En dat is ook wat whatsapp jaren heeft gedaan met kwaliteit van video en foto. Whatsapp is een noodzakelijk kwaad. Plus er worden je dingen door de strot geduwd die je helemaal niet wil.
Het is een upgrade want je krijgt betere kwaliteit geluid bij dezelfde bitrate. Ben je zo anti dat je zelfs een upgrade als downgrade neerzet?

Ik vind whatsapp prima werken. Het is gratis en heb niet het gevoel dat er 'dingen door mn strot geduwd worden'.
Nee. Dat is niet wat ik zeg.

Whatsapp is ‘gratis’. Meta verdient genoeg aan jou als gebruiker. Bellen, stickers, slechte kwaliteit media, status, er is voldoende dat door je strot geduwd wordt. Maar dat is dan blijkbaar mijn ‘anti’ mening.
Dit artikel gaat specifiek en alleen over een nieuw algoritme dat de audiokwaliteit van bellen verhoogd. Dat is alleen een verbetering en levert geen gui changes op.
Tenzij de client dit bij de handshake kan communiceren, wat tegenwoordig echt geen probleem meer is.
Ja leuk, maar dat is dus ook mijn punt; als het doelapparaat het niet ondersteunt levert het niets op...
Ja, en dan is dus mijn punt: dat hoeft geen drempel te zijn. Zolang je probleemloos kan differentieren wordt de gebruikerservaring niet slechter, mogelijk beter, en als het dan een superieure optie blijkt is het een kwestie van tijd voordat alle hardware ondersteuning biedt.
Om een POLQA MOS van 4 (goed) te krijgen, heb je rond de 7 kb/s nodig. Dat betekend dat een podcast van een uur slechts 3 MB inneemt. Opus heeft daar ongeveer het dubbele voor nodig.

Ik kan me ook voorstellen dat dit heel erg gaat helpen bij toekomstig bellen via satelliet netwerken. De bitrate naar mobiele devices is vaak heel laag, en dan kan dit een relatief makkelijke manier zijn om tweemaal zoveel gebruikers te kunnen ondersteunen.
Dat is eigenlijk best interessant, want dan zijn we nu zo ver qua audio compressie dat we voldoende hebben aan een 9600 bps modem om een gesprek verstaanbaar over internet te voeren. Hadden we dat in die tijd maar gehad
In de tijd dat 9600 bps modems nog gemeengoed waren, was internet nog niet voor consumenten beschikbaar. Toen XS4ALL als eerste begon, waren we net aan het overgaan van 14k4 naar 28k8 modems. De 56k6 waren puur voor internet toegang bedoeld (omdat het asymmetrisch was) en kwamen pas toen internet al veel bekender was.

Vergeet alleen niet dat de PC's van die tijd ook enorm veel moeite gehad zouden hebben met een moderne codec met veel floating point berekeningen. Sommige mensen hadden nog een PC zonder numerieke coprocessor, en de CPU van de gemiddelde PC was trager dan je magnetron nu :+

[Reactie gewijzigd door Llopigat op 22 juli 2024 22:03]

Ik heb nog wel een heel tijdje ingebeld met een GSM modem vanuit een vakantiehuisje die maar 9600 bps deed. Was redelijk betaalbaar toentertijd qua belminuten, zeker als je maar een uurtje internet nodig hebt. Maar sloom was het wel natuurlijk.
Ja ik ook... Ik heb zelfs vanuit Australie met girotel 'gebankierd', door in te bellen vanaf mijn GSM over een 9600 baud dialup verbinding naar Nederland :')

Het was wel duur maar girotel stuurde alles in een batch dus meestal was je toch niet meer dan een minuut verbonden.

Ik heb het ook wel eens gebruikt voor remote desktop maar dat was echt drama. Vooral toen de 'clippy' startte met alle animaties... Pff.

[Reactie gewijzigd door Llopigat op 22 juli 2024 22:03]

9600 baud is niet 9600 bps aangezien RS232 altijd 1 startbit en minstens 1 stopbit heeft en optioneel een pariteitsbit bij 8 databits. Het is dus maximaal 960Bps of 7680bps.
Momenteel gebruiken alle satteliet telefonie netwerken de codecs van DVSI, AMBE. Die waren altijd wel de koning van lage bandbreedte codecs maar deze scores zien er inderdaad wel beter uit. AMBE is ook al decennia oud.

Alleen satelliet telefonie heeft wel een probleem: het is vaak heel lastig te upgraden omdat de satellieten er jaren hangen. Ook is de codec meestal in hardware uitgevoerd in de toestellen.

Maar een netwerk als Starlink zou dit wel open kunnen breken omdat die beide nadelen niet hebben.
Hangt er natuurlijk vanaf hoe je die gesprekken verstuurt. Het zou me verwonderen dat ze de stream decoderen daarboven. Ik ga er van uit dat ze een generiek transportprotocol gebruiken.
Het hangt van de sats af, sommigen zijn hele domme "bent pipes" (zoals globalstar) en anderen doen best veel switching in de satteliet, zoals Iridium en Inmarsat. Van Thuraya weet ik het niet. Maar of ze echt de audio decoderen weet ik ook niet idd.
"Bij de ontvanger worden de banden weer door een encoder geleid om ze te comprimeren en een gecodeerde payload te genereren." dat klopt niet toch? Lijkt me dat dat een decoder voor decomprimeren moet zijn 😅😅
mjah. het plaatje hebben ze er zelfs onder gezet. beetje jammer.
En wanneer introduceren ze een codec die bij een normale verbinding ook een normaal gesprek mogelijk maakt? Als iemand mij via WhatsApp belt dan weiger ik het gesprek en bel ik ze terug via KPN / Vodafone / whatever, want anders is het gewoon niet te doen. Ook niet als beide telefoons vol bereik op fatsoenlijke wifi hebben.
Daar lijkt mij deze codec juist voor bedoeld te zijn? Dat ongeacht leeftijd en welke standaard codec de telefoon support, ze nu beiden deze gaan gebruiken.
Deze codec lijkt bedoeld om het geluid beter te maken bij weinig bandbreedte, en beide lijnen eindigen op hetzelfde niveau. Dat helpt dus niet wanneer er wel veel bandbreedte beschikbaar is.

Als het bij veel bandbreedte al ruk is dan huiver ik voor hoe het klinkt bij weinig bandbreedte. Ik wil best geloven dat deze nieuwe codec helpt, maar van heel ruk naar behoorlijk ruk is nog steeds ruk :+
Ik krijg regelmatig telefoontjes via WhatsApp, mijn ervaring is eigenlijk juist het tegenovergestelde. Ook onderweg in de auto via de carkit, prima helder geluid, geen issues of wat dan ook, thans aan mijn kant, al hoor ik de andere kant eigenlijk nooit klagen.
Wellicht ligt het aan je telefoon?
Ik ervaar juist het tegenovergestelde. Via Whatsapp bijna altijd kraakhelder geluid. Via de normale telefoonverbinding is vaak de kwaliteit echt minder.
Ik probeer te achterhalen of deze codec echt open source is, maar kan dat niet vinden. ChatGPT suggereert van wel, maar kan geen bronvermelding noemen. Iemand meer info?
ChatGPT hallucineert wel vaker. Het is closed source.

Zie https://opensource.fb.com/projects?search=&tags=audio , daar staat MLow niet tussen.
Dan is het een vrij kansloze missie als het doel verder gaat dan intern gebruik, bij bedrijfseigen en gesloten audio codecs werkt closed source eigenlijk al tientallen jaren niet meer.

[Reactie gewijzigd door zordaz op 22 juli 2024 22:03]

Waarom zorgt het splitsen van de frequentiebanden voor een betere compressie?
Zware compressie van beeld of geluid heeft vaak tot gevolg dat blokken in elkaar overlopen waardoor details uitgesmeerd worden over tijd of klanken samensmelten. Stemgeluid heeft een grondtoon, dit is de fundamentele frequentie van je stem en boventonen zoals de "S", "T" en "P" die essentieel zijn voor articulatie. Ik kan mij heel goed voorstellen dat als je beide in èèn keer comprimeert, je snel boventonen gaat verliezen. Als je gescheiden boven en ondertonen comprimeert en later weer over elkaar heen legt, voorkom je dat die twee gaan samensmelten tijdens het coderen en behoudt je de verstaanbaarheid langer met lagere bitrates. Ook kun je de grondtoon wat grotere blokken geven met minder detail en de boventonen wat meer detail.

[Reactie gewijzigd door martijn86 op 22 juli 2024 22:03]

Bedankt. Maar is het niet zo dat audiocompressie sowieso al werkt in het frequentiedomein, en daarna bepaalt wat er moet gebeuren op basis van een psycho-akoestisch model? Of is het vergelijkbaar met SBR, waar de hoge frequenties worden gegenereerd op basis van berekende harmonischen?
En wat winnen wij hiermee?
Betere geluidskwaliteit bij zelfde dataverbruik of minder dataverbruik voor zelfde kwaliteit geluid.

Op dit item kan niet meer gereageerd worden.