Qualcomm esitteli uuden AptX Lossless -teknologian CD-laatuisen äänen toistamiseen langattomasti

[Diizzel]

Qualcomm on lisännyt uuden AptX Lossless -teknologian jo keväällä esittelemäänsä Snapdragon Sound -ohjelmistoonsa. AptX Lossless on Bluetoothin kautta toistettavan äänen koodekki, joka tarjoaa nimensä mukaisesti häviötöntä ääntä langattomille kuulokkeille.

AptX Lossless tukee Quacommin mukaan 44,1 KHz:n 16 bittistä ääntä häviöttömänä ja yltää noin 1 Mbps:n bittivirtaan saakka. Teknologia tulee saataville valmistajan arvion mukaan kuluvan kalenterivuoden lopulla.

Lähde: Qualcomm

 

[hsalonen]

44.1*16 (16-bit)*2 (stereo) = 1.411Mbps.. Ei tuo nyt maailmoja mullistava pakkaus ole. Jos tuota kaistaa vaan olisi 41% enemmän, niin ei tarttisi miettiä codecceja ja pakkausta..

 

[pomk]

Ei tuo nyt maailmoja mullistava pakkaus ole.

Miten se edes voisi olla, häviötön kun on? Verrattavissa lähinnä flac pakkaukseen.

Edit: vai käyttiköhän flac jotain ihan perus rar tai zip pakkausta siinä taustalla, ei voi muistaa.

 

[hsalonen]

Miten se edes voisi olla, häviötön kun on? Verrattavissa lähinnä flac pakkaukseen.

Edit: vai käyttiköhän flac jotain ihan perus rar tai zip pakkausta siinä taustalla, ei voi muistaa.

Lähinnä nyt se, että nostamalla vähän kaistaa , ei tarvitse poropietaripakkauksia.

--

Eiköhän nämä mene jollain enemmän lähdemateriaalia ymmärtävällä pakkauksella, kuin Lempel-Ziv tai Huffman.

 

[BlackWolf]

Lähinnä nyt se, että nostamalla vähän kaistaa , ei tarvitse poropietaripakkauksia.

--

Eiköhän nämä mene jollain enemmän lähdemateriaalia ymmärtävällä pakkauksella, kuin Lempel-Ziv tai Huffman.

Onhan toi silti aina vähän kyseenalaista väittää "lossless" jos yleensäkkin pakataan.

 

[zepi]

Onhan toi silti aina vähän kyseenalaista väittää "lossless" jos yleensäkkin pakataan.

Miksi olisi? Ei wav-tiedoston zippaaminen ja unzippaaminen hävitä yhtään mitään informaatiota.

 

[BlackWolf]

Miksi olisi? Ei wav-tiedoston zippaaminen ja unzippaaminen hävitä yhtään mitään informaatiota.

Niin luuletko, että se live lähetys zipataan kun katsotaan vaikka elokuvaa?

 

[Hannibal]

Hyvä kysymys:

Lossless compression - Wikipedia

en.m.wikipedia.org

FLAC - Wikipedia

en.m.wikipedia.org

Sen mitä tuosta ymmärsin kyseessä on erityisesti musiikin palkkaamiseen erikoistunut pakkausalgorytmi. Eli geneerisen rar, zip etc eivät pääse lähellekkään flakin pakkauskykyä musiikin suhteen. 20% vs 50%-80%…

 

[BlackWolf]

Hyvä kysymys:

Lossless compression - Wikipedia

en.m.wikipedia.org

FLAC - Wikipedia

en.m.wikipedia.org

Sen mitä tuosta ymmärsin kyseessä on erityisesti musiikin palkkaamiseen erikoistunut pakkausalgorytmi. Eli geneerisen rar, zip etc eivät pääse lähellekkään flakin pakkauskykyä musiikin suhteen. 20% vs 50%-80%…

Tässä pitäisi ymmärtää, että nyt puhutaan audiosta, eli ensin pitää tehdä ääniaalloista ykkösiä ja nollia, siirtää ne ja sitten tehdä niistä taas ääniaaltoja. Sitten se kaikki pitäisi tehdä käytännössä sekunnin osissa, että esim. peleissä tai elokuvissa yms. ei äänet tule myöhässä. Esim. FLAC on hyvä asiassa, mutta se vaatii jerkkua siihen tekemiseen. Se ei toki haittaa jos kyseessä on musiikki CD tms. mutta mitään suoraa lähetystä ei paljoa FLAC:illa pakkailla tai siirrellä ja toisessa päässä pureta. AdptX teoriassa on liki lossless, mutta ei se kuitenkaan ole. Valitettavasti uutisessa oli vähän oiottu ja itseasiassa se virallinen lehtitiedote sanoo näin:

Qualcomm Technologies has taken a systems level approach and optimized a number of core wireless connectivity and audio technologies, including aptX Adaptive, which work together to auto detect and scale-up and are designed to deliver CD lossless audio when a user is listening to a lossless music file and the RF conditions are suitable.
Designed to work seamlessly together, these technologies deliver rates beyond 1Mbit/s yet smoothly scale down to 140kbits/s in congested RF environments to minimize any audio dropouts or glitches for a consistent and reliable listening experience.

Eli käytännössä ei voida yhtään sanoa, milloin tuo edes toimii. Ihan yhtä mahdollista on, että kyseessä on samantyylinen "no teoriassa" tason juttu kuin jossain langattomien siirtonopeuksissa kun ne on 2cm päässä toisistaan ja muuten ei toivoakaan. Boldasin oleellisen.

 

[pomk]

Tässä pitäisi ymmärtää, että nyt puhutaan audiosta, eli ensin pitää tehdä ääniaalloista ykkösiä ja nollia, siirtää ne ja sitten tehdä niistä taas ääniaaltoja. Sitten se kaikki pitäisi tehdä käytännössä sekunnin osissa, että esim. peleissä tai elokuvissa yms. ei äänet tule myöhässä. Esim. FLAC on hyvä asiassa, mutta se vaatii jerkkua siihen tekemiseen. Se ei toki haittaa jos kyseessä on musiikki CD tms. mutta mitään suoraa lähetystä ei paljoa FLAC:illa pakkailla tai siirrellä ja toisessa päässä pureta.

Tässä puhutaan vaan ykkösten ja nollien siirrosta digitaalilaitteelta toiselle, se että kyse on alun perin, ja siirron jälkeen, ääniaalloista on toissijaista.

Streamausyhteensopivan flac korvikkeen voi koodata kyllä jos sille on tarvetta. Ei pitäis olla mitään ongelmaa, mitä nyt pakkaustiheys hieman laskee.

Eli käytännössä ei voida yhtään sanoa, milloin tuo edes toimii. Ihan yhtä mahdollista on, että kyseessä on samantyylinen "no teoriassa" tason juttu kuin jossain langattomien siirtonopeuksissa kun ne on 2cm päässä toisistaan ja muuten ei toivoakaan. Boldasin oleellisen.

Ihan varmasti voidaan sanoa että milloin käytössä on se häviötön tila ja milloin ei. Sen näkee niistä bluetoothin yli lähetetyistä biteistä.

 

[BlackWolf]

Tässä puhutaan vaan ykkösten ja nollien siirrosta digitaalilaitteelta toiselle, se että kyse on alun perin, ja siirron jälkeen, ääniaalloista on toissijaista.

Streamausyhteensopivan flac korvikkeen voi koodata kyllä jos sille on tarvetta. Ei pitäis olla mitään ongelmaa, mitä nyt pakkaustiheys hieman laskee.


Ihan varmasti voidaan sanoa että milloin käytössä on se häviötön tila ja milloin ei. Sen näkee niistä bluetoothin yli lähetetyistä biteistä.

No ei ole "vain ykkösten ja nollien siirrosta". Sen vastaanottavan laitteen pitää se saatu data purkaa ja mahdollisimman nopeasti. Se, että sä pakkaat sen flac muotoon ja siirrät sitä bluetoothilla bitteinä on vasta osa operaatiota. Sitten jos sä teet sitä vielä striimistä lennossa etkä jo koodattua materiaalia, niin kaksi kertaa se pitää tehdä, audiosta dataksi, datan siirto ja datasta audioksi. Kaiken tän pitäisi tapahtua ilman, että vastaanottaja huomaa eroa lopputuloksessa ja viivettä on minimit. Kyseessä on nykyiselle kalustolle mahdoton tehtävä.

 

[Manager2k]

Miten Aptx HD eroaa sit tuosta 24bit, 48kHz, 576kbits ratella? Pienempi bit rate mutta yhä muuten parempi?

 

[pomk]

Miten Aptx HD eroaa sit tuosta 24bit, 48kHz, 576kbits ratella? Pienempi bit rate mutta yhä muuten parempi?

AptxHD ei ole häviötön pakkaus. Ts. puretut bitit ei oo samat kuin mitä pakattiin.

audiosta dataksi

Tää on tehty jo musiikin tuotantovaiheessa, vai meinaatko että tätä koodekkia käytettäis jossain kasettinauhureissa? Kyse on siitä että dataa pakataan, siirretään toiseen laitteeseen ja puretaan siellä, se että kyseiset bitit muodostavat musiikkia on melko toissijaista kun kyse on häviöttömästä pakkauksesta.

No ei ole "vain ykkösten ja nollien siirrosta". Sen vastaanottavan laitteen pitää se saatu data purkaa ja mahdollisimman nopeasti.

Jep. Tuo yleensä toteutetaan siten, että ”streamattava” matsku pakataan sellaisella algoritmilla, jolla saadaan pakattua tiedostoa purettua lineaarisesti temporaalisen dimension suhteen. Yleensä mitä vähemmän pakataan, niin sitä helpommin ja nopeammin tuo onnistuu. En nyt jaksa katsoa että kuinka monta samplea kerrallaan esim. sillä flacilla on pakko bufferoida.

Edit: flac purku onnistuu 16kt bufferilla (1Mt/s siirtonopeudella tarkoittaa n. 16ms viivettä) cd laatuiselle musiikille ja itseasiassa on täysin streamattava formaatti ja soveltuisi periaatteessa tähänkin käyttöön. Pakkausviive lienee pykälän isompi kuin tuo, riippuen käytössä olevista laskentaresursseista.

 

[Kaakatus]

No ei ole "vain ykkösten ja nollien siirrosta". Sen vastaanottavan laitteen pitää se saatu data purkaa ja mahdollisimman nopeasti. Se, että sä pakkaat sen flac muotoon ja siirrät sitä bluetoothilla bitteinä on vasta osa operaatiota. Sitten jos sä teet sitä vielä striimistä lennossa etkä jo koodattua materiaalia, niin kaksi kertaa se pitää tehdä, audiosta dataksi, datan siirto ja datasta audioksi. Kaiken tän pitäisi tapahtua ilman, että vastaanottaja huomaa eroa lopputuloksessa ja viivettä on minimit. Kyseessä on nykyiselle kalustolle mahdoton tehtävä.

Eihän tässä missään luvata, että viiveet olisi minimit ja pelkkää musiikkia striimatessa parin sekunnin viiveelläkään ei ole mitään merkitystä. Aptx Adaptive oletettavasti sitten vaihtaa johonkin low latency moodiin, jos viivettä pitää karsia.
44,1KHz/16bit CD-laatuisella äänellä tämä on häviötön siirtomuoto, kun yhteys sen sallii. Kenttätestit sitten kertovat, että miten usein tähän päästään.

Miten Aptx HD eroaa sit tuosta 24bit, 48kHz, 576kbits ratella? Pienempi bit rate mutta yhä muuten parempi?

Bluetooth toteutusten dynamiikka harvoin pääsee yli 16bitin, eikä äänitteilläkään sellaista dynamiikkaa ole, joten hyödyt jäävät vähiin. 48KHz hyödyttää videoiden kanssa, ettei tarvitse resamplata 48-> 44KHz, mutta jälleen nämä kuuloalueen yli menevät taajuudet tuppaavat huuhtoutumaan jo bluetooth toteutusten heikkouksiin. Lopuksi meille jää, bitrate joka ei riitä edes sen CD-tasoisen äänen siirtoon mistään HD-audiosta puhumattakaan. Pahinta ei kuitenkaan ole nämä luvut, vaan ne käytännön toteutukset. Tässä hyvä esimerkki bluetooth vastaanottimesta ja sen eri codeceista: Topping BC3 Review (Bluetooth Receiver) & BT CODECs

LDAC on testissä aivan omassa luokassaan ja toivon todella, että tämä uusi Aptx Lossless tuo Qualcommin toteutuksen vähintään samalle viivalle. Aptx Lossless on laajennus nykyiseen Aptx Adaptive perheeseen, eli kaikki esim. korkeammat näytteenottotaajuuset onnistuvat, mutta niiden pakkaus muuttuu häviölliseksi.

 

[_j03_]

Onhan toi silti aina vähän kyseenalaista väittää "lossless" jos yleensäkkin pakataan.

Eihän siinä ole yhtään mitään kyseenalaista jos vaan käytetään häviötöntä pakkausta.

 

[JiiPee]

Niin luuletko, että se live lähetys zipataan kun katsotaan vaikka elokuvaa?

Jos satuit vaikka olympialaisia katsomaan, siis livelähetyksiä niin kyllä ne lähetykset on "zipattu" niin videon kuin audion osalta. Olet nyt tekemässä kärpäsestä härkästä väittämällä ihan puutaheinää että ei pystytä lennossa pakkaamaan ja purkamaan.

Kyllä itsekin muistan niitä aikoja kun ämpeekolmosia alettiin tehä CD:stä ja se pakkaaminen kesti ikuisuuden mutta ajat on muuttunu siitä ja esim. testasin tuossa juuri niin i4790K jurnuttaa mp3 encoodausta yli 60x nopeudella ja ihan single core kuormaa toi.

 

[pomk]

Kyllä itsekin muistan niitä aikoja kun ämpeekolmosia alettiin tehä CD:stä ja se pakkaaminen kesti ikuisuuden mutta ajat on muuttunu siitä ja esim. testasin tuossa juuri niin i4790K jurnuttaa mp3 encoodausta yli 60x nopeudella ja ihan single core kuormaa toi.

Ja flac:in pakkaus ja purku on vielä dramaattisesti tuota nopeampaa. Jo athlon 2400+ jurnuttaa tuota 54 - 134x nopeudella. Tämä aptx lossless on luultavasti vaan flac pienillä muutoksilla.

Edit: ja ton flac algon kun vielä optimoisi vain yksille pakkusparametreille ja jollekkin tietylle käskykannalle (kuten tämän aptx losslessin kohdalla on mahdollista tehdä), niin uskoisin että nopeutusta olisi saatavilla ihan reilusti.

 

[JaniKari]

BT 5 versio toi supportin 2mbps nopeudelle joka periaatteessa mahdollistaa cd-laadun lähettämisen. Valitettavasti tämä nopeus toteutuu vain lyhyillä etäisyyksillä vähä häiriöisissä paikoissa (= vähän wlan liikennettä). Tämän takia pakkauksesta täytyy tehdä dynaaminen jotta ääni ei pätkisi kun radio yhteys heikkenee vähänkään. Parhaimmillaan tämä uusi codec on siis (käytännössä) häviötön ja huonoimmillaan tavallinen codec miten radio yhteys toimii.

 

[pomk]

Parhaimmillaan tämä uusi codec on siis (käytännössä) häviötön

Ei, vaan ihan oikeasti häviötön, ainakin saatavilla olevien materiaalien mukaan. Tästä vaihdetaan sit lennossa johonkin aivan toiseen pakkaukseen jos havaitaan että signaalitasot heikkenee liikaa.

 

[Konepelaaja88]

Harmi että 99% 80-luvun jälkeen tehdyistä albumeista on ylikompressoitu täysin pilalle jolloin häviöttömyys ei tuo paljon etuja ellei kuuntele klassista tai vanhoja albumeita 80-luvulta. Tämä on suuri sääli kun lossless tekniikka toisi oikeasti musiikin "korvalle".

 

[emagdnim]

Harmi että 99% 80-luvun jälkeen tehdyistä albumeista on ylikompressoitu täysin pilalle jolloin häviöttömyys ei tuo paljon etuja ellei kuuntele klassista tai vanhoja albumeita 80-luvulta. Tämä on suuri sääli kun lossless tekniikka toisi oikeasti musiikin "korvalle".

Jep, tästä löytyy youtubestaki paljon esimerkkejä tällaiselle ei-kultakorvallekkin. Mitä noihin bt-codeikkeihin, niin sbc:n kyl huomaa jo iha puhe-äänessäkin. Puuroa. Muuten vaatii tarkempaa keskittymistä, jos koittaa esim. aptx / ldac eroja löytää. Ehkä, jos vaihtelis livenä, mut ei oo tullu kokeiltua. Mut mieki oon mp3-ajan nuori

 

[Konepelaaja88]

Jep, tästä löytyy youtubestaki paljon esimerkkejä tällaiselle ei-kultakorvallekkin.

Jepo koska ne erot kuulee kaikista parhaiten kun musiikki on hyvin dynaamista ja laitteet ovat kunnolliset. Jos äänite soi kokoajan lujaa vaikka voluumisäädin on melkein nollassa niin hankala edes teoriassa huomata eroa häviöttömän vs häviöllisen välillä ellei häviöllinen ole pakattu pienellä bittivirralla. Tällainen musiikki soveltuu kyllä hyvin kuntosaleille, juhannusbileisiin jossa ei tavoitella niin hyvää äänentoistoa kun taustalla on enemmän häiriötekijöitä mutta jos on tarkoitus kuunnella hiljaisessa paikassa kuten olo/makuuhuoneessa laadukkailla kuulokkeilla/kaiuttimilla niin laadukas dynaaminen ääni pääsee näissä oikeuksiinsa ja sitä jaksaakin kuunnella pitkään.

 

[tonkar]

SBC on kelvollinen, valitettavasti joissain laitteissa se on säädetty päin honkia.

Bluetooth SBC Dual Channel HD audio mode

Deep dive into the

www.lineageos.org

 

[Teemu79]

Jep, hyvin toteutettu SBC > tyypillinen AptX.

Noita hyviä SBC toteutuksia onkin sitten harvassa...

 

[zepi]

Oletan, ettö SBC:n pitää olla hyvä nimenomaan lähettävässä päässä, purkukodekkihan ei voi sonnasta tietenkään repiä hyvää signaalia ulos.

Miten määritellään hyvä SBC-toteutus, miten se mitataan ja onko esimerkkejä sellaisesta?

 

[Teemu79]

Nokia BH-905, vuosimallia 2009. Äänenlaatu on ollut täysin verrannollinen saman hintaluokan AptX luureihin aivan viime vuosiin asti. Olet oikeassa että lähettävällä päällä on luultavasti enemmän merkitystä, mutta vuosien saatossa tuli vastaan vain yksi Android -tabletti jonka lähettämä ääni oli selkeästi kuraa. Olennaisimmat erot eri (lähettävien) laitteiden välillä ovat olleet "huojunnassa" ja kantamassa.

 

[pulatunnus]

Eihän tässä missään luvata, että viiveet olisi minimit ja pelkkää musiikkia striimatessa parin sekunnin viiveelläkään ei ole mitään merkitystä.

Parinsekunnin viive voisi jo tuntua käyttökokemuksessa, jos vaihdat kappeletta,lukua, kelaat jne. menee sekuntti kaksi ennenkuin korvissa, jos vielä suoratoistopalvelu, niin sen palvelun viiveet päälle.

Mutta hyviöpointteja, jos pakkaukseen ympättyvirheenkorjaus jne, eli voidaan ne jättää siirtotiestä pois, niin antaahan se hitusen pelivaraa.

Jos käytetään videomateriaalin kanssa, niin eiköhän viiveet ole aika pienet ja pärjää hyvin kuvaviiveen kanssa, jokatapauksessa ne pitää synkata riittävällä tarkkuudella.

44,1KHz/16bit CD-laatuisella äänellä tämä on häviötön siirtomuoto, kun yhteys sen sallii. Kenttätestit sitten kertovat, että miten usein tähän päästään.

Häviöttömän eduksi kai voi laskea sen että toimii häviöllisten materiaalien kanssa, vaikka optimi kai olisi että käytään sitä mitä materiaali. (jos kuvitellaan että vastaanottaja hanskaa parhaalla tavalla sen)

Bluetooth toteutusten dynamiikka harvoin pääsee yli 16bitin, eikä äänitteilläkään sellaista dynamiikkaa ole, joten hyödyt jäävät vähiin.

Totta, ja mikä olisi se käyttökohde jossa voisi jotenkin hyödyntää edes 16bit dynamiikan. jos pysytään edes jotekin tontilla.

. 48KHz hyödyttää videoiden kanssa, ettei tarvitse resamplata 48-> 44KHz, set onnistuvat, mutta niiden pakkaus muuttuu häviölliseksi.

Maalikkona luulisi juurikin tälläisten asioiden olevan eduksi, (siis se ettei tarvi alkaa uudestaan käpisteleen, vaan mahdollisimman natiivisti perille saakka, asia sitten erikseen jos lähde rajusti yli bittinen / ylinäytteistetty, jossa varaa karsia)

 

[Ormu]

Onhan toi silti aina vähän kyseenalaista väittää "lossless" jos yleensäkkin pakataan.

Jos pakattu äänidata on palautettavissa bitintarkasti samanlaiseksi kuin se oli ennen pakkausta, kyseessä on häviötön pakkaus. Tässä ei ole mitään kyseenalaista.

Pakkauksen vaatima aika eli siitä johtuva viive on eri asia, ja se voi olla ongelma jossain sovelluksessa ja jossain toisessa ei. CPU:lla ja softalla toteutettuna viivettä tulee todennäköisesti enemmän kuin tarkoitukseen tehdyllä erillisellä piirillä.


Se näissä häviöttömissä pakkauksissa mietityttää, että niiden pakkaussuhde riippuu väistämättä enemmän pakattavan datan ominaisuuksista. Joku yksinkertainen signaali voi pakkautua hyvinkin tehokkaasti, satunnaiskohina taas ei juuri lainkaan. Häviöllisellä pakkauksella voidaan taata joku yläraja vaadittavalle siirtonopeudelle, jolloin monimutkaisempi data vain huononee enemmän. Häviöttömällä siirtonopeusvaatimuksen mitoittaminen on haastavampaa.