Hur kan vi som konsumenter skynda på införandet av EBU R128?

[Svante]

Jag vet inte det. Jag kan bara konstatera att olika lyssningssituationer och anläggningar kan påkalla behov av en mer begränsad dynamik än R128 föreskriver. ...

Nu är jag inget proffs på EBU R128 utan bara en lekman som bara läst vad andra skrivit om standarden, men R128 "föreskriver" ingen dynamik alls. Man får ha mycket eller lite dynamik på sitt programmaterial, det är upp till den som skapar materialet. Det viktiga är att medelnivån inte läggs starkare än -23 LUFS.

Man får alltså tokkomprimera materialet hur mycket man vill, men EBU R128 ser till att materialet inte låter starkare än andra mer dynamiska material. Därmed hoppas man att incitamentet för att tokkomprimera ska försvinna.

Jo, men;
Om standarden föreskriver en nivå som gör att allt musikameterial som produceras för att användas i portabla spelare (antar då användning i relativt bullrig miljö) eller i fordon leder till att 10 dB headroom aldrig eller sällan används. Vad är då poängen(?) och Om materialet utnyttjar den dynamik som standarden medger så leder det till att man i oftast kommer behöva komprimera för att kunna tillgodogöra sig musiken även i bil, etc. Att komprimera vid uppspelningstillfället är (i mitt tycke) en allt för grov kompromiss, d.v.s. något som bör undvikas.

Detta headroom finns i lågnivåsignalen före slutsteget. Om det bara finns tillräcklig gain tillgänglig kan man få ut full effekt ändå.

Det enda problemet som kvarstår är det att slutsteg med för lite effekt kan ha svårt att återge ett material med hög dynamik. Detta kan bättras på lite genom att apparater med låg uteffekt ges ett snyggt klippbeteende eller tom en kompressor som begränsar signalen snyggt. Tokmastering när det absolut behövs, mao, i stället för att göra den på allt material alltid.

[Svante]

Lustigt. Jag tolkade några LU till som att standarden skulle kunna innefattat några fixa, fördefinierade olika LUFS-ar t.ex.:
B. -23 LUFS (broadcasting)
C: -33 LUFS (high dynamic range material - klassisk musik,...)
P: -13 LUFS (low dynamic material for portable use, car audio, ...)

Det vore att motverka hela syftet med R128.

Jag vet inte det. Jag kan bara konstatera att olika lyssningssituationer och anläggningar kan påkalla behov av en mer begränsad dynamik än R128 föreskriver. Jag har en platta på lager, inspelad live och med en crest-faktor mycket nära 23 dB och i bullriga miljöer, som t.ex. i bilen blir de starka passagerna väl starka om man vill kunna höra de svagare partierna. Min tanke är att sälja olika versioner, med olika komprimering. Mer dynamik på CD och högupplöst format och mindre på MP3-versionen. Inte preliminärt för att formaten skulle begräns utan p.g.a. av hur de typiskt används.

Det du pratar om här är terrassdynamik, dvs att olika delar av en låt är olika starka. Det är absolut så att sådana låtar kan behöva jämnas ut, men det är inte det vi talar om när vi talar om tokmaximering, typiskt. Det är i stället när man distorderar signalen för att höja medelnivån. Det är skillnad på det och att jämna ut svaga och starka partier nivåmässigt.

Oavsett vilket så tjänar alla på om alla ser till att alla inspelningar låter lika starkt, i stället för som idag att de som låter starkast låter mest illa och får en att vrida ner volymkontrollen, och gör att nästa låt som låter bra nästan inte hörs alls om man vrider upp volymen.

[Laila]

....
Oavsett vilket så tjänar alla på om alla ser till att alla inspelningar låter lika starkt, i stället för som idag att de som låter starkast låter mest illa och får en att vrida ner volymkontrollen, och gör att nästa låt som låter bra nästan inte hörs alls om man vrider upp volymen.

Glömt ett "inte" . . . typ ?

[IngOehman]

Ja, ett efter "man", eller också saknar ett "ens" före "om". Med många av dagens bärbara spelare, för att inte tala om bärbara datorers inbyggda spelare och högtalare, är det faktiskt så illa att det inte är säkert att det räcker ens om man drar volymen i botten. Konstigt egentligen att det inte finns något hack som gör att man kan få 20-30 dB extra gain på laptoppar.

- - -

Med det sagt har inte Svante alldeles rätt... Alla lyssnare tjänar måhända på det, men alla tjänar inte på det. De som tidigare skaffade sig konkurrensfördelar genom att låta starkare än de som prioriterade ljudkvalitet, kommer inte att tjäna på det. Det kommer att förlora sitt övertag då det kommer att bli rättvist.

Det är lite som att den som vill bestämma över och ta från alla andra andra med våld, och som har våldspotentialen, förlorar på kombinationen "en lag som säger att man inte får stjäla + ett samhälle med ännu större våldspotential, som kan vidmakthålla lagen".

Det är lite av det som R128 kan hoppas bli.

Och det är inte bara skurkar med vapen som vill skaffa sig fördelar på andras bekostnad som hindras, även de som känner sig tvugna att ta till samma metoder fast de inte vill slipper göra det när ingen får göra det. Lägga sig över -23 LUFS alltså.

(Ursäkta om liknelsen blev för svår.)


Vh, iö

[Laila]

Däälalugntvetdu . . . typ.

[IngOehman]

Ja att du hänger med förstår jag ju.


Vh, iö

[RogerJoensson]

Ja, ett efter "man", eller också saknar ett "ens" före "om". Med många av dagens bärbara spelare, för att inte tala om bärbara datorers inbyggda spelare och högtalare, är det faktiskt så illa att det inte är säkert att det räcker ens om man drar volymen i botten. Konstigt egentligen att det inte finns något hack som gör att man kan få 20-30 dB extra gain på laptoppar.

För Mac finns Audio Hijack Pro, som kan insertas före ljudkortet eller efter ett program. Den har inbyggd gainreglage som ger 6dB extra, behöver man ha mer så lägger man till en plugin, eller flera i serie.
Denna använder jag mycket till gamla filmer för att kröka rätt diskantstympning och brustvätt som filmbolagen försett DVD-utgåvorna med.

För Windows finns http://www.virtualaudiostream.com från http://www.ddmf.eu, som är klart sämre (bl a begränsad till 16 bitars upplösning och inte värdens bästa ditherbrus eller vad nu brusgolvet beror på). Ibland om man spelar högdynamisk film på hög volym så kan ett mycket svagt brus höras i tysta passager, men som helhet är det inga problem. Det finns inget gainreglage heller, men inte heller något som hindrar att man letar upp en VST-plugin som gör jobbet med Vitrual Audio Stream som motor.
Jag använder den då och då på surfplattan i stugan när något behöver skruvas till (film).
DDMFs IIEQPro har ett gainreglage som kan ge upp till 24dB förstärkning t ex.

[IngOehman]

Är alltså IIEQPro något som jag kan installera på min XP-maskin bara sådär?


Vh, iö

[RogerJoensson]

Jag vet inte hur det funkar under XP (min surfplatta kör W8.1), men det står att Virtual Audio Stream finns för XP...

Man behöver både streamingmotorn och t ex IIEQPro (en VST-plugin som inte funkar fristående).

[Ogjort]

Nylig kontakt med Tomas Lund (f.d. TC Electronics) som varit drivande i R 128-frågan redan från början, meddelar att han är ordförande i den grupp inom CENELEC som tillsats för att se över toppnivåbegränsningen i våra mobiltelefoner. De har möte i september och beslut om höjning av nivån för att ge ökad möjlighet till R 128-standard kan komma redan i november 2015.

Så... man ska kanske hålla en lite tumme!

[IngOehman]

Om du har något inflytande över snubben, så hjälp honom att hjälpa dem att komma ihåg att det är minst lika viktigt, faktiskt till och med viktigare, att det finns tillräckligt med gain.

För lite gain är R128s värsta fiende - eftersom det får folk att tycka att R128 är en dålig ide.

Om det klipper för att toppnivån är begränsad så är det förstås inte så bra, men går det inte att dra upp så att det låter lagom starkt så är det MYCKET värre.


Vh, iö

[Ogjort]

Jag tolkar det som att det är just det som är målet.

Men jag tror också att Tomas välkomnar kloka synpunkter.
Så kontakta mig Ingvar, så ska jag se till att ni får tala med varandra. (på danska då förstås)

/ Anders O.

[hcl]

Nylig kontakt med Tomas Lund (f.d. TC Electronics) som varit drivande i R 128-frågan redan från början, meddelar att han är ordförande i den grupp inom CENELEC som tillsats för att se över toppnivåbegränsningen i våra mobiltelefoner. De har möte i september och beslut om höjning av nivån för att ge ökad möjlighet till R 128-standard kan komma redan i november 2015.

Så... man ska kanske hålla en lite tumme!

Det går m.a.o.t rätt håll.

Man undrar över varför de inte begränsar max medelnivå (integrerat över någon lämplig tid) istället? Det hade ju löst i stort sett hela problemet. Det hade varit väldigt enkelt det med.

[Svante]

Nylig kontakt med Tomas Lund (f.d. TC Electronics) som varit drivande i R 128-frågan redan från början, meddelar att han är ordförande i den grupp inom CENELEC som tillsats för att se över toppnivåbegränsningen i våra mobiltelefoner. De har möte i september och beslut om höjning av nivån för att ge ökad möjlighet till R 128-standard kan komma redan i november 2015.

Så... man ska kanske hålla en lite tumme!

Det går m.a.o.t rätt håll.

Man undrar över varför de inte begränsar max medelnivå (integrerat över någon lämplig tid) istället? Det hade ju löst i stort sett hela problemet. Det hade varit väldigt enkelt det med.

Det är svårare att göra i elektroniken. Max toppvärde begränsas av matningsspänningen, begränsning av det K-vägda medelvärdet kräver att det mäts och regleras. Det måste förmodligen ske i mjukvara.

[hcl]

Nylig kontakt med Tomas Lund (f.d. TC Electronics) som varit drivande i R 128-frågan redan från början, meddelar att han är ordförande i den grupp inom CENELEC som tillsats för att se över toppnivåbegränsningen i våra mobiltelefoner. De har möte i september och beslut om höjning av nivån för att ge ökad möjlighet till R 128-standard kan komma redan i november 2015.

Så... man ska kanske hålla en lite tumme!

Det går m.a.o.t rätt håll.

Man undrar över varför de inte begränsar max medelnivå (integrerat över någon lämplig tid) istället? Det hade ju löst i stort sett hela problemet. Det hade varit väldigt enkelt det med.

Det är svårare att göra i elektroniken. Max toppvärde begränsas av matningsspänningen, begränsning av det K-vägda medelvärdet kräver att det mäts och regleras. Det måste förmodligen ske i mjukvara.

Jo, men ändå. Relativt simpelt jämfört med all signalbehandling som pågår i en mobiltelefon.

[Svante]

Det går m.a.o.t rätt håll.

Man undrar över varför de inte begränsar max medelnivå (integrerat över någon lämplig tid) istället? Det hade ju löst i stort sett hela problemet. Det hade varit väldigt enkelt det med.

Det är svårare att göra i elektroniken. Max toppvärde begränsas av matningsspänningen, begränsning av det K-vägda medelvärdet kräver att det mäts och regleras. Det måste förmodligen ske i mjukvara.

Jo, men ändå. Relativt simpelt jämfört med all signalbehandling som pågår i en mobiltelefon.

Du ville ha en förklaring, och man ska minnas att när reglerna bestämdes så var det vanligt med ipodar och andra dedicerade musikspelare. Sådana kan man sätta ihop med några färdiga chip som gör mp3-avkodning och sköter knappar och display.

[petersteindl]

Vad blev det av detta?

SONY Corporation tillsammans med the Recording Industry Association of America RIAA Warner Music Group och Apple Inc. har infört en ny standard på allt inspelat ljud som sätter stop för all extrem tokmastring.

Music Industry Shipments Data Revitalized
The RIAA shipment report is for the first time including crest factors from synchronization of recorded music with other content (such as movies, TV, video games, or other media) as well as from all recorded music without other content. This is a complementary standard to the red book standard for audio CDs (Compact Disc Digital Audio system) and is included in BD-5, BD-9 and BDXL formats by Blu-ray Disc Association, and Warner Home Video. The most essential change is that any crest factors below 12.5 can no longer be offered with this new normalization of 12.5 in crest factor.

At the request of many mastering engineers, we’ve also added a feature to the database that allows adjustment of crest factors for dynamic inflation on all recorded materials.

We are excited that users continue to report the needs for a standardized crest factor that can be compared with statistics, and that the database of standardized recorded music has become recognized as a definitive source for industry data.

We believe that these new features offer real additional value to users and we believe that the loudness war hereby is solved.

Cary Sherman - Recording Industry Association of America
Kevin Kelleher - Sony Music Entertainment
Philip W. Schiller - Apple Inc.
Paul Robinson - Warner Music Group

Nu skall det ursprungliga vitala återinföras. Tillsammans har de satt en normaliserad standard så att allt inspelat ljud skall hamna på en och samma crestfaktor på 12,5. Därmed är alla tokmastringar med crestfaktorer på mindre än 12,5 ett minne blott och loudness war har gått i graven. Hurra för standardisering.

MvH
Peter

[IngOehman]

Det går m.a.o.t rätt håll.

Man undrar över varför de inte begränsar max medelnivå (integrerat över någon lämplig tid) istället? Det hade ju löst i stort sett hela problemet. Det hade varit väldigt enkelt det med.

Det är svårare att göra i elektroniken. Max toppvärde begränsas av matningsspänningen, begränsning av det K-vägda medelvärdet kräver att det mäts och regleras. Det måste förmodligen ske i mjukvara.

Jo, men ändå. Relativt simpelt jämfört med all signalbehandling som pågår i en mobiltelefon.

Nej, det är så långt ifrån "relativt simpelt" som man kan komma. Det är helt omöjligt att åstadkomma det du talar om i realtid. Svante var mycket blygsam när han skrev "svårare att göra". Det är inte svårare, det är omöjligt.

Man kan åstadkomma något som kan påminna om det - sett ur ett analysinstruments synvinkel, men inte utan att förstöra musiksignalen illa med just det man vill undvika - kompression/undervägs nivåförändring.

Orsaken är att medelvärdesbegränsning är att ställa nivån på ett helt stycke, således att medelvärdet blir det avsedda (t ex -23 dB i fallet R-128) och för att man skall kunna göra det så behöver man känna till nivån på HELA stycket, i varje ögonblick, INNAN man stället nivån således att medelvärdet blir rätt.

I realtidsspelningssituationen finns helt enkelt inte den information som behövs tillgänglig.

Man vet bara hur starkt det är just nu och hur starkt det har varit, men man vet ingenting om hur starkt det kommer att vara framåt, tills låten är slut.

Så ända sättet att i realtid reglera medelnivån är att ändra gain under det att låten spelas, det vill säga förstöra de dynamiska förloppen - vilket ju var precis vad man vill undvika. Det är liksom hela kärnan med R-128 att de som skapar musiken skall ha kreativ frihet - att musiksignalen INTE skall förstöras efteråt.

- - -

Däremot finns det utmärkta exempel på fall där man kan vilja realtidsprocessa för att anpassa till den specifika lyssningsmiljön, t ex i en bullrig bil. Och även i det fallet är en vanlig kompressor, t ex en sådan som man ofta använder vid masting, fel verktyg. Det verktyg man behöver är ett som både kan lyfta svaga detaljer i musiken över en tröskel (t ex en vanlig additiv kompressorprocess) men som inte förstör transientdynamiken) och en återkoppling från lyssningsmiljön (t ex en akustisk mätning av störnivån, eller en framkoppling baserat på rådande hastighet, det finns många sätt man kan göra det på) som påverkar önskad tröskelnivå.

Men även om man har tillgång till sådana system så är R-128 en i grunden utmärkt utgångspunkt eftersom det gör att oddsen att programmaterialet är mindre preprocessat således att man kan anpassa signalprocessningen till just den specifika lyssningsmiljö som är aktuell.

- - -

Sammanfattningsvis:

1. Den nivåbestämning som R-128 erbjuder gör att programmaterialet kan få vara av väsentligt högre ljudkvalitet (om producenterna vill det) än i en situation där loudness war tvingar fram ljudkvalitetsförsämringar - drivna av önskan att hävda sig loudnessmässigt. Fortfarande kan man självklart komprimera sitt programmaterial hur mycket man vill, men man behöver inte längre göra det av kommersiella skäl.

2. Ett programmaterial som uppfyller R-128 är i sig en utmärkt som utgångspunkt för den som vill processa ett programmaterial vidare - t ex för uppspelning i en bullrig miljö som i en bil. Den processningen i sin tur, görs bäst med utökad indata, läs bullernivåinformation, med i ekvationen.

3. Den nivåreglering som R-128 hjälper till med, kan INTE åstadkommas i en realtidsprocess, eftersom nivåavgörandet bara kan göras med HELA låten tillgänglig.


Vh, iö

[hcl]

Det är svårare att göra i elektroniken. Max toppvärde begränsas av matningsspänningen, begränsning av det K-vägda medelvärdet kräver att det mäts och regleras. Det måste förmodligen ske i mjukvara.

Jo, men ändå. Relativt simpelt jämfört med all signalbehandling som pågår i en mobiltelefon.

Nej, det är så långt ifrån "relativt simpelt" som man kan komma. Det är helt omöjligt att åstadkomma det du talar om i realtid. Svante var mycket blygsam när han skrev "svårare att göra". Det är inte svårare, det är omöjligt.

Man kan åstadkomma något som kan påminna om det - sett ur ett analysinstruments synvinkel, men inte utan att förstöra musiksignalen illa med just det man vill undvika - kompression/undervägs nivåförändring.

Orsaken är att medelvärdesbegränsning är att ställa nivån på ett helt stycke, således att medelvärdet blir det avsedda (t ex -23 dB i fallet R-128) och för att man skall kunna göra det så behöver man känna till nivån på HELA stycket, i varje ögonblick, INNAN man stället nivån således att medelvärdet blir rätt.

I realtidsspelningssituationen finns helt enkelt inte den information som behövs tillgänglig.

Man vet bara hur starkt det är just nu och hur starkt det har varit, men man vet ingenting om hur starkt det kommer att vara framåt, tills låten är slut.

Så ända sättet att i realtid reglera medelnivån är att ändra gain under det att låten spelas, det vill säga förstöra de dynamiska förloppen - vilket ju var precis vad man vill undvika. Det är liksom hela kärnan med R-128 att de som skapar musiken skall ha kreativ frihet - att musiksignalen INTE skall förstöras efteråt.

- - -

Däremot finns det utmärkta exempel på fall där man kan vilja realtidsprocessa för att anpassa till den specifika lyssningsmiljön, t ex i en bullrig bil. Och även i det fallet är en vanlig kompressor, t ex en sådan som man ofta använder vid masting, fel verktyg. Det verktyg man behöver är ett som både kan lyfta svaga detaljer i musiken över en tröskel (t ex en vanlig additiv kompressorprocess) men som inte förstör transientdynamiken) och en återkoppling från lyssningsmiljön (t ex en akustisk mätning av störnivån, eller en framkoppling baserat på rådande hastighet, det finns många sätt man kan göra det på) som påverkar önskad tröskelnivå.

Men även om man har tillgång till sådana system så är R-128 en i grunden utmärkt utgångspunkt eftersom det gör att oddsen att programmaterialet är mindre preprocessat således att man kan anpassa signalprocessningen till just den specifika lyssningsmiljö som är aktuell.

- - -

Sammanfattningsvis:

1. Den nivåbestämning som R-128 erbjuder gör att programmaterialet kan få vara av väsentligt högre ljudkvalitet (om producenterna vill det) än i en situation där loudness war tvingar fram ljudkvalitetsförsämringar - drivna av önskan att hävda sig loudnessmässigt. Fortfarande kan man självklart komprimera sitt programmaterial hur mycket man vill, men man behöver inte längre göra det av kommersiella skäl.

2. Ett programmaterial som uppfyller R-128 är i sig en utmärkt som utgångspunkt för den som vill processa ett programmaterial vidare - t ex för uppspelning i en bullrig miljö som i en bil. Den processningen i sin tur, görs bäst med utökad indata, läs bullernivåinformation, med i ekvationen.

3. Den nivåreglering som R-128 hjälper till med, kan INTE åstadkommas i en realtidsprocess, eftersom nivåavgörandet bara kan göras med HELA låten tillgänglig.

Vh, iö

Det fundamentalistiska svaret, får jag väl erkänna, är väl att det är svårt (inte omöjligt, läs lång buffring av dat), men det är både en onödig och oönskad lösning. Kmpressor med långsam reaktionstid och ännu långsammare släpp skulöe lösa proböemet, nöjaktigt bra och troligen bättre än en maxbegränsare, vilket var målet.

[Svante]

Det beror ju på vad man pratar om för apparat, men om man antar att det är filer som är lagrade på en filspelare så har man ju hela låten tillgänglig. Då kan man åtminstone i princip mäta nivån i låten och begränsa den K-vägda medelnivån utifrån det. Man kan också tänka sig att filerna är märkta med metadata som gör att man inte behöver mäta medelnivån, det tar trots allt lite tid som förmodligen kommer att slöa ner responsen på spelaren lite.

Problemet är att det kommer att dyka upp felmärkta filer som gör att de spelas för starkt...

Man kan också tänka sig en kombination, om filerna är märkta börjar man spela upp filen baserat på det, men mäter i bakgrunden, stämmer det inte ändrar man volymen. Det stimulerar till att filer ska vara rättmärkta.

Man kan också tänka sig att spelaren märker filerna så fort man lägger dem i magen på den.

Kvar finns direktsänd radio, där måste materialet vara preprocessat så att det håller tillräckligt låg nivå. Även där kan man tänka sig krav på att spelaren mäter under gång och kompenserar sådant som har fel nivå med dynamikförändring som följd. Material som är riktigt justerat från början spelas rätt.

Detta är som sagt betydligt krångligare att få robust mot loudnessrejsare som vill lura systemet och mot dynamikpåverkan, men idag är det kanske görbart och mycket bättre än den toppvärdesbegränsning som finns idag.

[arkman]

Det är precis så det fungerar i många mediaspelare. I JRiver har man implementerat EBU R128 och det fungera på det sätt som Svante beskrivit. Programmet går igenom alla musikfiler, analyserar nivån och skriver ner info i metadata för varje musikfil. När man sedan spelar upp filen så anpassas nivån till värdet som finns i metadata. För att dra nytta av funktionen så måste man aktivera en DSP-funktion och man måste ställa in importfunktionen så att den kör igenom analysen när nya filer importeras.
Jag har testat det här lite grann och sett att JRiver gör någon form av nivåreglering då funktionen är aktiverad även om analysen inte är gjord. Jag gissar att programmet gör en grov beräkning av nivån innan det startar uppspelningen.
För mer info, se länk: http://wiki.jriver.com/index.php/Volume_Leveling

JRiver kallar nivåregleringen för "Volume Leveling" och jag trodde ett tag att man kunde anta att om musikspelen har något som kallas för "Volume Leveling" så är det standarden EBU R128 som tillämpas men så verkar det trots allt inte vara. I en annan musikspelare - Roon Lab så finns också funktionen Volume Leveling men då är det den "gamla" Replay Gain som används.

[Svante]

Ja, och sedan måste då det där kombineras med reglementet som idag säger att toppvärdet inte får vara mer än si och så. Alltså att man i stället ser till att den K-vägda medelnivån inte överskrider ditt och datt i stället.

Volymreglering är ett av syftena med R128, diskussionen om spelarna handlar om hur starkt de ska få spela i absoluta tal. Ur hörselskadesynpunkt då.

[arkman]

Jag undrar om den här toppvärdesbegränsningen i bl.a. mobiltelefoner har någon betydande funktion. Ibland lyssnar jag via ett par Sennheiser HD800 som är ganska tungdrivna och ibland via ett par iPod-lurar. När jag lyssnar via HD800 så måste jag ofta stänga av nivåbegränsningen för att få en vettig ljudnivå på vissa inspelningar. Det blir mycket svårt att göra en nivåbegränsning som tar hänsyn till hur tungdrivna lurarna är, men funktionen är naturligtvis inte till för dom som lyssnar med lurar som HD800 utan främst för att föräldrar ska kunna begränsa nivån som deras barn lyssnar på.

[Svante]

Ja och barn är uppfinningsrika... Nej det är inget lätt problem att lösa eftersom ingen har fullständig kontroll på hårdvaran och eftersom de man vill skydda inte riktigt förstår vad det innebär att ha en hörselskada.

[IngOehman]

Jo, men ändå. Relativt simpelt jämfört med all signalbehandling som pågår i en mobiltelefon.

Nej, det är så långt ifrån "relativt simpelt" som man kan komma. Det är helt omöjligt att åstadkomma det du talar om i realtid. Svante var mycket blygsam när han skrev "svårare att göra". Det är inte svårare, det är omöjligt.

Man kan åstadkomma något som kan påminna om det - sett ur ett analysinstruments synvinkel, men inte utan att förstöra musiksignalen illa med just det man vill undvika - kompression/undervägs nivåförändring.

Orsaken är att medelvärdesbegränsning är att ställa nivån på ett helt stycke, således att medelvärdet blir det avsedda (t ex -23 dB i fallet R-128) och för att man skall kunna göra det så behöver man känna till nivån på HELA stycket, i varje ögonblick, INNAN man stället nivån således att medelvärdet blir rätt.

I realtidsspelningssituationen finns helt enkelt inte den information som behövs tillgänglig.

Man vet bara hur starkt det är just nu och hur starkt det har varit, men man vet ingenting om hur starkt det kommer att vara framåt, tills låten är slut.

Så ända sättet att i realtid reglera medelnivån är att ändra gain under det att låten spelas, det vill säga förstöra de dynamiska förloppen - vilket ju var precis vad man vill undvika. Det är liksom hela kärnan med R-128 att de som skapar musiken skall ha kreativ frihet - att musiksignalen INTE skall förstöras efteråt.

- - -

Däremot finns det utmärkta exempel på fall där man kan vilja realtidsprocessa för att anpassa till den specifika lyssningsmiljön, t ex i en bullrig bil. Och även i det fallet är en vanlig kompressor, t ex en sådan som man ofta använder vid masting, fel verktyg. Det verktyg man behöver är ett som både kan lyfta svaga detaljer i musiken över en tröskel (t ex en vanlig additiv kompressorprocess) men som inte förstör transientdynamiken) och en återkoppling från lyssningsmiljön (t ex en akustisk mätning av störnivån, eller en framkoppling baserat på rådande hastighet, det finns många sätt man kan göra det på) som påverkar önskad tröskelnivå.

Men även om man har tillgång till sådana system så är R-128 en i grunden utmärkt utgångspunkt eftersom det gör att oddsen att programmaterialet är mindre preprocessat således att man kan anpassa signalprocessningen till just den specifika lyssningsmiljö som är aktuell.

- - -

Sammanfattningsvis:

1. Den nivåbestämning som R-128 erbjuder gör att programmaterialet kan få vara av väsentligt högre ljudkvalitet (om producenterna vill det) än i en situation där loudness war tvingar fram ljudkvalitetsförsämringar - drivna av önskan att hävda sig loudnessmässigt. Fortfarande kan man självklart komprimera sitt programmaterial hur mycket man vill, men man behöver inte längre göra det av kommersiella skäl.

2. Ett programmaterial som uppfyller R-128 är i sig en utmärkt som utgångspunkt för den som vill processa ett programmaterial vidare - t ex för uppspelning i en bullrig miljö som i en bil. Den processningen i sin tur, görs bäst med utökad indata, läs bullernivåinformation, med i ekvationen.

3. Den nivåreglering som R-128 hjälper till med, kan INTE åstadkommas i en realtidsprocess, eftersom nivåavgörandet bara kan göras med HELA låten tillgänglig.

Vh, iö

Det fundamentalistiska svaret, får jag väl erkänna, är väl att det är svårt (inte omöjligt, läs lång buffring av dat), men det är både en onödig och oönskad lösning. Kmpressor med långsam reaktionstid och ännu långsammare släpp skulöe lösa proböemet, nöjaktigt bra och troligen bättre än en maxbegränsare, vilket var målet.

Nej, det vore en totalkatastrof, och ingalunda ett sätt varken att behålla dynamiken eller ens att se till så att filen får rätt medelvärde!

Enda sättet att se till så att medelvärdet för all historik i varje ögonblick har rätt medelvärde, är att ha en snabb kompressor, och resultatet av det blir en förstörd transientdynamik. Men även en långsam (som är katastrofal för resultatet, långsam attacktid kan kommer i total motfas med programmaterialet och dra ned så sent att bara något svagt som kommer efteråt blir nivådämpat ) kompressor går bet sett ur ljudkvalitetssynvinkeln, och som sagt, den kan missa på medelvärdet också, gravt. Långsamma kompressorer är förfärliga. De går inte att ha till just någonting. Möjligen undantaget som "kontrollsystem" för typ en leverantör av radiomaterial som försöker övermodulera sändaren. Då kan det vara rimligt att använda en gain-rider-funktion. Syftet är ju då inte att skapa ljudkvalitet, utan snarare att "straffa ut" dåliga beteenden. Den som försöker övermodulera en sändare genom att dra upp för mycket, drabbas helt enkelt av en sändare som drar ned, mer och mer, ju mer den som försöker övermodulera drar upp. Enda sättet att inte trigga sådan skyddsfunktion och på så vis vidmakthålla en hög ljudkvalitet, blir att låta bli att sända med för högt medelvärde.

- - -

Dock har du rätt i att en lång buffring (lika lång som låten) av data är en lösning, men då är det ju inte realtidslyssning längre. Då är det inspelning/uppspelning. Det vill säga man kan göra nivåbedömningen baserat på HELA filen som utgör låten.

Och dessutom - hur vet man hur lång en låt är i förväg = Hur vet man hur länge man behöver buffra? Det kan man inte veta. Men även om man från högre ort bestämde att varje låt var max tre minuter lång (och därmed basta!) så hjälper inte det om önskemålet är att det skall vara realtidslyssning, för det kräver ju att man INTE buffrar.


Vh, iö

- - - - -

PS. Jag tror möjligen att det som gör de här resonemangen kan vara lite svåra att hänga med i, är att många har en väldigt förenklad bild av vad en "låt" är för något, och glömmer att all musik inte är nivåjämn schlager.

Det finns inte bara medelvärde och sen lite transientdynamik på det, utan det finns massor av musik som har kraftigt skild nivå i olika delar (stor terassdynamik) och utöver det så finns det ju programinslag som kan innehålla båda tal och tystnad. Det är långt ifrån självklart att man vill att det skall vara jämnstarkt hela tiden.

Man hade allt varit hårt komprimerad och terassdynamikfri schlagermusik så hade det varit en smal sak att lägga nivåerna rätt med de metoder liknande de som hcl nämner.

[hcl]

Nej, det är så långt ifrån "relativt simpelt" som man kan komma. Det är helt omöjligt att åstadkomma det du talar om i realtid. Svante var mycket blygsam när han skrev "svårare att göra". Det är inte svårare, det är omöjligt.

Man kan åstadkomma något som kan påminna om det - sett ur ett analysinstruments synvinkel, men inte utan att förstöra musiksignalen illa med just det man vill undvika - kompression/undervägs nivåförändring.

Orsaken är att medelvärdesbegränsning är att ställa nivån på ett helt stycke, således att medelvärdet blir det avsedda (t ex -23 dB i fallet R-128) och för att man skall kunna göra det så behöver man känna till nivån på HELA stycket, i varje ögonblick, INNAN man stället nivån således att medelvärdet blir rätt.

I realtidsspelningssituationen finns helt enkelt inte den information som behövs tillgänglig.

Man vet bara hur starkt det är just nu och hur starkt det har varit, men man vet ingenting om hur starkt det kommer att vara framåt, tills låten är slut.

Så ända sättet att i realtid reglera medelnivån är att ändra gain under det att låten spelas, det vill säga förstöra de dynamiska förloppen - vilket ju var precis vad man vill undvika. Det är liksom hela kärnan med R-128 att de som skapar musiken skall ha kreativ frihet - att musiksignalen INTE skall förstöras efteråt.

- - -

Däremot finns det utmärkta exempel på fall där man kan vilja realtidsprocessa för att anpassa till den specifika lyssningsmiljön, t ex i en bullrig bil. Och även i det fallet är en vanlig kompressor, t ex en sådan som man ofta använder vid masting, fel verktyg. Det verktyg man behöver är ett som både kan lyfta svaga detaljer i musiken över en tröskel (t ex en vanlig additiv kompressorprocess) men som inte förstör transientdynamiken) och en återkoppling från lyssningsmiljön (t ex en akustisk mätning av störnivån, eller en framkoppling baserat på rådande hastighet, det finns många sätt man kan göra det på) som påverkar önskad tröskelnivå.

Men även om man har tillgång till sådana system så är R-128 en i grunden utmärkt utgångspunkt eftersom det gör att oddsen att programmaterialet är mindre preprocessat således att man kan anpassa signalprocessningen till just den specifika lyssningsmiljö som är aktuell.

- - -

Sammanfattningsvis:

1. Den nivåbestämning som R-128 erbjuder gör att programmaterialet kan få vara av väsentligt högre ljudkvalitet (om producenterna vill det) än i en situation där loudness war tvingar fram ljudkvalitetsförsämringar - drivna av önskan att hävda sig loudnessmässigt. Fortfarande kan man självklart komprimera sitt programmaterial hur mycket man vill, men man behöver inte längre göra det av kommersiella skäl.

2. Ett programmaterial som uppfyller R-128 är i sig en utmärkt som utgångspunkt för den som vill processa ett programmaterial vidare - t ex för uppspelning i en bullrig miljö som i en bil. Den processningen i sin tur, görs bäst med utökad indata, läs bullernivåinformation, med i ekvationen.

3. Den nivåreglering som R-128 hjälper till med, kan INTE åstadkommas i en realtidsprocess, eftersom nivåavgörandet bara kan göras med HELA låten tillgänglig.

Vh, iö

Det fundamentalistiska svaret, får jag väl erkänna, är väl att det är svårt (inte omöjligt, läs lång buffring av dat), men det är både en onödig och oönskad lösning. Kmpressor med långsam reaktionstid och ännu långsammare släpp skulöe lösa proböemet, nöjaktigt bra och troligen bättre än en maxbegränsare, vilket var målet.

Nej, det vore en totalkatastrof, och ingalunda ett sätt varken att behålla dynamiken eller ens att se till så att filen får rätt medelvärde!

Enda sättet att se till så att medelvärdet för all historik i varje ögonblick har rätt medelvärde, är att ha en snabb kompressor, och resultatet av det blir en förstörd transientdynamik. Men även en långsam (som är katastrofal för resultatet, långsam attacktid kan kommer i total motfas med programmaterialet och dra ned så sent att bara något svagt som kommer efteråt blir nivådämpat ) kompressor går bet sett ur ljudkvalitetssynvinkeln, och som sagt, den kan missa på medelvärdet också, gravt. Långsamma kompressorer är förfärliga. De går inte att ha till just någonting. Möjligen undantaget som "kontrollsystem" för typ en leverantör av radiomaterial som försöker övermodulera sändaren. Då kan det vara rimligt att använda en gain-rider-funktion. Syftet är ju då inte att skapa ljudkvalitet, utan snarare att "straffa ut" dåliga beteenden. Den som försöker övermodulera en sändare genom att dra upp för mycket, drabbas helt enkelt av en sändare som drar ned, mer och mer, ju mer den som försöker övermodulera drar upp. Enda sättet att inte trigga sådan skyddsfunktion och på så vis vidmakthålla en hög ljudkvalitet, blir att låta bli att sända med för högt medelvärde.

- - -

Dock har du rätt i att en lång buffring (lika lång som låten) av data är en lösning, men då är det ju inte realtidslyssning längre. Då är det inspelning/uppspelning. Det vill säga man kan göra nivåbedömningen baserat på HELA filen som utgör låten.

Och dessutom - hur vet man hur lång en låt är i förväg = Hur vet man hur länge man behöver buffra? Det kan man inte veta. Men även om man från högre ort bestämde att varje låt var max tre minuter lång (och därmed basta!) så hjälper inte det om önskemålet är att det skall vara realtidslyssning, för det kräver ju att man INTE buffrar.


Vh, iö

- - - - -

PS. Jag tror möjligen att det som gör de här resonemangen kan vara lite svåra att hänga med i, är att många har en väldigt förenklad bild av vad en "låt" är för något, och glömmer att all musik inte är nivåjämn schlager.

Det finns inte bara medelvärde och sen lite transientdynamik på det, utan det finns massor av musik som har kraftigt skild nivå i olika delar (stor terassdynamik) och utöver det så finns det ju programinslag som kan innehålla båda tal och tystnad. Det är långt ifrån självklart att man vill att det skall vara jämnstarkt hela tiden.

Man hade allt varit hårt komprimerad och terassdynamikfri schlagermusik så hade det varit en smal sak att lägga nivåerna rätt med de metoder liknande de som hcl nämner.

Mycket handlar om att sätta rimliga tidskonstanter (f.f.a. mycket längre release tid än vad man har normalt). Betänk att åtgärden vore som ett alternativ till det vi har nu, väldigt tidig topplimitering. Nåja, detta är en relativt onödig diskussion i.o.m. att man nu tycks kommit överens om ett vettigt sätt att hantera det hela. Jag var mest förvånad över att man inte kommit på något bättre än en lågt satt maxnivå, tidigare. Det hade ju gått att göra, med tämligen rimlig insats, och rimligare negativpåverkan för lyssnaren. Som jag ser det.

[IngOehman]

Att topplimitering är väldigt dumt tror jag vi är överens om.

Vi tycks dock inte vara överens om att alla sortera kompressorer är minst lika illa.

Och jag vet inte om vi är överens om att det största problemet med många av dagens mobila avspelare är att de har otillräcklig gain, men det är ett mycket större problem för högdynamiskt programmaterial, är den begränsade toppnivån, hur konstigt det är kan låta.


Vh, iö

[hcl]

Att topplimitering är väldigt dumt tror jag vi är överens om.

Vi tycks dock inte vara överens om att alla sortera kompressorer är minst lika illa.

Och jag vet inte om vi är överens om att det största problemet med många av dagens mobila avspelare är att de har otillräcklig gain, men det är ett mycket större problem för högdynamiskt programmaterial, är den begränsade toppnivån, hur konstigt det är kan låta.

Vh, iö

Jag tror vi är ganska överens. Möjligen är jag något mer öppen för att kompression är något som i flera fall är önskvärt, nära på nödvändigt. Jag skulle dock se att det då i första hand tillämpas i mix-ledet och att programmaterialet distribueras i flera versioner, lämpade för olika förhållanden.

[IngOehman]

Jag håller inte med alls. Vill rent av gå som långt som till att säga att det är det sämsta man kan göra.

OM kompression (annan än sådan som har med produktionen att göra, t ex en kompressor lagd på en basist för att få det "rätta soundet") behövs i någon lyssningssituation, så är det ALLTID bäst att åstadkomma denna på plats, där behovet finns.

Där och bara där kan man optimera processningen för situationen, som t ex i en bil med hög (och varierande) bullernivå. Där på plats så kan man ju lägga tröskelnivån olika beroende på momentanbullret (som går att mäta på platsen, om man inte helt enkelt återkopplar hastigheten) och man kan även göra tröskelnivån oberoende av volyminställningen, det vill säga komprimera mera underifrån, när man spelar svagare.

Att komprimera programmaterialet i förväg leder bara till att det inte finns något val. Det är kört när man vill slippa höra kompressionen.

Du nämnde i och för sig att det kan finnas flera versioner, men jag ser ingen nytta med att ha tillgång till någon annan version än en okomprimerad. Det är alltid den bästa utgångspunkten, även när man tänker processa programmaterialet i avspelningsled.


Vh, iö

[Svante]

Så Märta Svensson, 92, som tycker att det är lite för stor skillnad på starkt och svagt ska alltså utrustas med en kompressor och kanske då också en bruksanvisning som förklarar vad attack, threshold, och ratio betyder? Hur stor chans är det att det lyckas tro?