- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Hasonlóan alacsony bitrátát tud mint a https://github.com/google/lyra
- A hozzászóláshoz be kell jelentkezni
Szerk.: vegyesek vele szemben az érzéseim. Procin próbáltam csak ki egyelőre, de már itt voltak vele gondok. 16 szál helyett csak 5-6 szálat használt, a betömörítési ideje egy 2,5 perces jazz hangmintának kb. 2,5 perc, de a kitömörítése már 3 perc. Egy nem gyenge procin (Ryzen 7 6800H, ami majdnem egy Threadripper 1920 szintjén van) nincs meg a valós idejű kikódolás. Izmos NV GPU-ja meg nincs mindenkinek. Nekem csak egy gyengébb van, egy RTX 3050 mobil Ti, ahhoz fel kell raknom majd a drivert, hogy ki tudjam próbálni.
A másik a minősége. Nem lenne rossz, de az Opus 16-32 kbps-on eléggé megközelít, de a hardverigénye töredéke, elfut bármint, valós időben kikódol. Így ennek a TSAC-nek maximum csak ilyen kísérleti jelleggel van értelme egyelőre.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
A Transformer szamitasigenyes. Szerencsere a szamitas jellege pont jo a GPU-nak, ill. az ujabb CPU utasitasoknak. Szoval ez idovel javulni fog, de tech demonak mar ez is eleg jo.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
"Nekem csak egy gyengébb van, egy RTX 3050 mobil Ti"
Elég lesz bőven az is.
- A hozzászóláshoz be kell jelentkezni
Ja, kis is fogom próbálni, csak az egy kis idő lesz, vagy mert fel kell patkolni az NV + CUDA drivert, vagy Windowra kell átbootolni (ami nem tettem meg már majdnem egy éve).
Jelenleg Linuxon szándékosan nem használok NV-t, a prociba integrált RDNA2-es mobil Radeon 680M is elég erős azokhoz a játékokhoz, felbontáshoz, amit néha használok.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Mint 1999-ben az mp3. Kellett egy kis prociidő mire betömörült, igaz a lejátszás simán ment bármin.
Lehet, hogy desktop cpu-n érdemesebb próbálkozni, az csak gyorsabb 10-12x, meglenne a valósidejű kikódolás.
- A hozzászóláshoz be kell jelentkezni
Egy asztali proci ehhez képest nem 10-12x gyorsabb. Vannak persze, gyorsabbak, erősebb asztali Ryzen 7-9 a 7-8. generációból meg Core i7-i9 12-13. genből, de az se lényegesen gyorsabb, talán annyit segítenének azok, hogy a valós idejű lejátszás meglenne, de épp hogy csak, annyira a határon, hogy mellette nem sokat tudnád a háttérben a gépet használni.
Már pedig ilyen audiocodec-eknél, ha általános használatra lesz, akkor cél szokott lenni, hogy egy táblagépen, meg embedded eszközön is menjen, ha túl bika hardver kell hozzá, akkor értelmét veszti.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Tippre itt nem az volt a cel, hogy egy embedded eszkozon mukodo codecet keszitsen. Persze van, hogy vegul az jon ki, de eleg sok jo otlete volt mar Bellardnak. A TCC peldaul egy IOCCC nyertes C forditobol lett.
Sok helyen olvastam mar, hogy itt az AI, es hogy milyen jo tomoritot fognak majd vele csinalni, mert felismeri a kozos mintazatokat. Szerintem kivancsi volt ra, hogy mit tud belole kihozni.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Azért értelme nem sok volt.
- A hozzászóláshoz be kell jelentkezni
Még lehet. Ha 10 év múlva lesz olyan SoC, ami izomból kezeli, valami LoRa Mesh szerű hálón hang küldésére jó is lehet valami hasonló megoldás. Zenére viszont nem jó, azért még a botfülemnek is sértő volt néhány hiba nagyobb bitrátán is.
- A hozzászóláshoz be kell jelentkezni
Ez eddig tipikus problemaja volt az osszes ilyen machine learning-alapu codecnek, a fentebb emlitett google-os lyra-nak, a facebook-altal fejlesztett encodec-nek is. Nagyon alacsony bitratan tud "turheto" minoseget, viszont hiaba emeled a bitratat, a minosegen nem tudsz javitani.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
Kutatas. Sokszor nem tudod elore, hogy mi fog kijonni, lehet hasznalhato meg hasznalhatatlan is.
Watsonek teljesen ertelmetlenul alkottak meg a kettos spiral elotti DNS szerkezeteiket, az elso mukodo gozgep elotti probalkozasok is total ertelmetlenek voltak, meg a nem mukodo repulo szerkezetek is a Wright testverek elott (sokan bele is haltak). De talan valamit segitettek abban, hogy a vegen a mukodo megoldas is elkeszuljon.
Szerintem volt ertelme, mert most lehet tudni kb. meddig lehet eljutni transzformeres hangtomoritessel. Egyebkent nincs kizarva, hogy ha 1D (hang) helyett 2D-vel csinalta volna (kepekkel), jobb eredmenyt er el.
A strange game. The only winning move is not to play. How about a nice game of chess?
- A hozzászóláshoz be kell jelentkezni
Ez biztosan nem értelmetlen projekt, mert a Googlenek van egy hasonló fejlesztése, az is nagyságrendileg ilyen bitrátát tud és működik minden átlagos Android mobilon. Duo, mostmár sajnos Meet-be beolvasztva app-nak a hangcodecje. Biztos vagyok benne ez is fog kapni a közeljövőben optimalizációkat amivel lejjebb megy az erőforrásigénye, természetesen modern hardveren (gpu, avx...) és nem őskövület 20 éves pc-ken.
- A hozzászóláshoz be kell jelentkezni
Ez is AI által kidolgozott tömörítés. Azért is kell hozzá GPU, vagyis azért van arra tervezve, mert mátrixokkal számol, nem diszkrét algoritmus alapján tömörít, mint a oggenc, opusenc, lame mp3, twolame, qaac, flac, stb..
Érted, így nettó értelmetlen, mert oké, csoda GPU-n jól fut, de amelyik gépben van ilyen, abban van 1-2 tera tárhely is, és akár FLAC-ot is használhatsz. Az ilyen apróra tömörített dolgoknak mobil, embedded eszközön van értelme, ahol tényleg alig pár megás tárhelyed van, és az ultraenergiatakarékos feldolgozás is fontos, meg nem tudsz rá gigabites netet, meg modern Wi-Fi-t kötni.
Ráadásul ha még csak a betömörítés lenne lassú, azt csinálnád dedikált gépen, de a lejátszás még lassabb, azt meg hol játszod le? Ja, kicsomagolod lejátszás előtt, de oh wait, akkor meg lossless + tsac méretet fog úgyis foglalni, nem leszel megint előrébb egy FLAC-hoz képest, max. ha csak a netes sévszélességgel spórolás volt a cél.
Igen, 10-20 év múlva lehet a lightos hardverek, integrált GPU-k is viszik, de akkor meg elavult lesz, lesznek még modernebb tömörítések, codec-ek.
Így ma aki gyakorlatban is használható codec-et akar irtó alacsony bitrátán, annak Opust ajánlok. A minősége kb. párban van ezzel a TSAC-vel, igaz dupla akkora bitrátán, de még úgy is elenyésző KiB-ot foglal csak egy audio file, nem lesz közötte sokkoló különbség, ilyen 100-200 KB különbségen egy 2-3 perces audio fájlnál senkinek nem fog múlni az élete, cserében elmegy egy kenyérpirítón is, és 1 mp. alatt tömöríti be ugyanazat a fájlt, amit a TSAC-nek 2-3 percbe telik.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
> asztali proci ehhez képest nem 10-12x gyorsabb
nem (csak) a ghz szamit, hanem a memoria savszelesseg (foleg AI dolgoknal, a sok nagy weights miatt), es az utasitaskeszlet (amd nem ismerem, intelnel az avx2, avx512 utasitaskeszlet dob siman 10x-20x is az AI szamolasnal)
> egy táblagépen, meg embedded eszközön is menjen
ezekben mar regota van AI-gyorsito GPU vagy CPU utasitaskeszlet, mert mar minden is (kezdve pl. a camera app-al) hasznal AI-t.
> ha túl bika hardver kell hozzá, akkor értelmét veszti
emlexem 98-ban az mp3 is epphogy ment realtime az akkori overclockolt celeronomon. azota egyreszt gyorsabb cpu-k vannak, masreszt optimalizaltak sebessegre a codecet.
- A hozzászóláshoz be kell jelentkezni
Csak a lényeg nem derül ki: lossless vagy sem?
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
- A hozzászóláshoz be kell jelentkezni
Ekkora méretnél csont mindegy. Ott fogják használni, ahol a méret a kritikus, nem a minőség.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Hogy a fenébe lenne lossless? Vagy hogy úgy érted, van-e olyan kódolási módja? Arra én se találtam semmit.
Elvileg le lehetne tárolni a különbséget a tömörített és eredeti hanganyag között. Arra kíváncsi lennék, úgy mennyit hozna.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, hogy lossless-e, de úgy gondolom ez egy olyan alapvető információ, aminek az első mondatban benne kéne lennie a readme-ben.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
- A hozzászóláshoz be kell jelentkezni
Elvileg le lehetne tárolni a különbséget a tömörített és eredeti hanganyag között. Arra kíváncsi lennék, úgy mennyit hozna.
Nemcsak elvileg, pont erre épül a legtöbb modern codec, pl. a FLAC és a HVEC is (a különbség általában kevesebb biten tárolható, ráadásul több benne az ismétlődés, így jobban is tömöríthető, ezért éri meg nagyon).
- A hozzászóláshoz be kell jelentkezni
Nem teljesen.
A helyzet az, hogy a veszteséges tömörítést máshogy érdemes csinálni, ha az a cél, hogy az eredmény érzékszervi úton befogadható legyen, és máshogy ha a veszteségmentességhez szűkséges különbség minimalizálása a cél.
Amit leírtál, arra az elvre az ún. hybrid codec-ek épülnek, ahol van egy külön veszteséges tömörítési fázis (ami önmagában is működőképes) és utána van egy reziduális vagy delta tömörítési fázis, ami elrakja a maradék eltérést az eredetihez képest. A FLAC nem ilyen, ugyan használ belső (pontatlan) predikciót, de ez külön nem elérhető, valószínűleg nem volt értelme kivezetni, mert nem produkált használható eredményt. Volt például a wavpack, ami ilyen volt (illetve létezik is, csak nem terjedt el), tudott egy-egy lossy és lossless-delta file-párba tömöríteni és a lossy file önállóan is hallgatható minőségű volt. A HEVC-nek tudtommal nincs lossless üzemmódja, elvileg az utána következő VVC-ben van (bár nem igazán sikerült működésre bírnom eddig).
Ellenpéldának fel tudom még hozni a Jpeg XL-t, aminek a lossy és a lossless üzemmódja két totálisan különböző formátum, teljesen más kódolási módszerrel.
Régóta vágyok én, az androidok mezonkincsére már!
- A hozzászóláshoz be kell jelentkezni
elvileg a TrueHD (ebben van egy onalloan is hasznalhato AC3 sav) es a DTS-HD (DTS az alapsav) is ilyenek
bar mar van vagy 15 eve hogy ezzel foglalkoztam :)
- A hozzászóláshoz be kell jelentkezni
Azért, mert megától érthetődőnek gondolta. Ilyen alacsony méretnél csak lossless játszik. Ezt te is ellenőrizheted, betömörítesz vele egy rövid hangmintát, majd kicsomagolod új fájlnéven, diff-fel összehasonlítod, nagyon durván nem fog egyezni.
Nekem a weboldalán a kb/s nem volt egyértelmű, de megfejtettem, 1000 bit/sec-ot ért alatta, nem KiB-ot.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Feltételezem, hogy lossy-ra gondoltál lossless helyett.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
- A hozzászóláshoz be kell jelentkezni
Arra hát, csak félreírtam. Most már szerkeszteni se tudom, de mindegy.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
- A hozzászóláshoz be kell jelentkezni
Megnéztem a kódot (vagyis amire épül, mert a tsac maga nem nyílt forráskódú, ha jól látom. tsac is based on a modified version of the Descript Audio Codec)
Ez egy adatvesztéses (lossy) tömörítés, amihez külön tömörítve letárolódik a különbség ("Residual"), emiatt lesz a végén veszteségmentes (lossless) az eredmény.
A különbséget tároló blokkokat kihagyva könnyedén még kissebbé, de veszteségesé tehető a formátum. Ráadásul szabályozhatóan, mert ha jól látom, a veszteségmentes eredményhez 3-szor számítódik residual korrekció. Ha mondjuk csak kétszer számolná, akkor is kissebb lenne a fájl, de jóval pontosabb (de még mindig lossy) lenne az eredmény.
- A hozzászóláshoz be kell jelentkezni