Fórumok
Sziasztok!
Milyen szoftvert javasolnátok MP3 hangjerejének növelésére?
Illetve, van-e olyan amivel megtudható milyen erősségre van beállítva.
Lehet-e több fájlt is így megváltoztatni egyetlen menetben?
Előre is köszi a segítséget.
Hozzászólások
Összebarkácsoltam egy ilyen parancsot:
ffmpeg -i "filename" -filter:a volumedetect -f null /dev/null~
Ez rengeteg dolgot kiír csak több olyan szó is van benne amiben a volume megtalálható...
Szóval jól jönne valami segítség.
Még nincs aláírásom.
A Google szerint:
https://www.raeallen.net/2020/04/29/use-ffmpeg-to-measure-loudness-of-a…
https://gist.github.com/bulletinmybeard/96ede6c4c19e3ffb7ff3be1145bc0723
Ha már ffmpeg, akkor mondjuk +20%-os hangerő növeléshez:
ffmpeg -i "filename" -filter:a "volume=1.2" -c:a -f mp3 "destination"
Ezt a kérdést nem tudom értelmezni. Normalizálni szeretnél?
find "dir" -name "*.mp3" -exec <a futtatandó parancs> \;
Köszi!
Igazából szeretném megtudni, hogy amelyik mp3 hangereje tetszik, annál mennyi az érték.
Utána pedig az összeset arra beállítani, fixen. Ez tehát változó mennyiséget jelenthet több esetben is.
Ezért kellene tudnom egy pontos értéket, és a többit pontosan arra beállítani. Így a példának felhozott "volume=1.2" paraméter rossz eredményt adna. gondolom...
Még nincs aláírásom.
A hangerő emelése gyakran dinamika csökkenést jelent.
A legtöbb wave hangfájl -32768 - 32767 között bármilyen értéket felvehet. Az átlag mondjuk legyen 5000, tehát egy halk zene, ezt akarod 10.000-re emelni, ami dupla hangos. Magyarul kicsit megszűröd az ugrásokat, hogy -16384 - 16383 tartományba essen, majd duplázod az amplitúdót és láss csodát, 2x olyan hangos lesz.
Vedd félhangra az új fájl hangerejét és hasonlítsd össze az eredetivel. Hallani fogod, hogy bár hangosabb lett, de zajosabb is mellette.
Nyilván azért váltott az ipar, mert a pórnép a hangerőre izgul, nem a dinamikára. Emiatt az újabb mp3-ak nagyobb hangerőn alacsonyabb dinamikával lettek felvéve.
Nem nagyon értek a hangfájlokhoz. Én mp3 témában szeretnék utazni, ahhoz a wave taglalása nekem furcsának tűnik. Bár azt is el tudom képzelni, hogy az mp3 igazából csak egy jól becsomagolt és tömörített wave. Végül is lehet, hogy mindegy.
Ami fontos nekem, hogy a hangerő beállítását, ami lehet emelés vagy csökkentés is, úgy szeretném elérni, hogy minimális legyen a torzítás. Vagyis, ha lehet, akkor a "zajosabb" az legyen minél kisebb. Ez működhetne akár mp3 állományok esetében is?
Még nincs aláírásom.
Minden lehetséges, de torzítás az lesz. Persze nem biztos hogy kihallod, főleg ha hangos a zene, tele dobbal.
Az mp3-at wav-ba kell kódolni, majd normalizálni, majd vissza mp3-ba. Minden program ezt csinálja, ha 1 lépésben, akkor is.
Az mp3 veszteséges, hangerő növelésre meg nem való. Az eredetit tartsd meg.
OK, torzítás az lesz. Mi a válasz - még torzítás esetén is - arra a két kérdésre, hogy:
1. Hogyan tudom megállapítani egy adott mp3 esetében, hogy milyen hangerő értékre van beállítva?
2. Hogyan tudom az összes többi mp3-at pontosan arra az értékre átalakítani?
Még nincs aláírásom.
Vegyük Verditől a rabszolgák kórusát. Mi a hangos, mi a halk?
Honnan tudja a normalizáló program felismerni, hogy ez most forte, az meg piano? Von egy átlagot és az lesz a norma.
Nagyon sok szubjektív dolog van szerintem az egyenlő hangerő érzetben. Te tudod, hogy ez most a forte, a program meg nem. Normalizálsz mindent és ugyanolyan zűrzavar lesz, mint előtte.
Szerintem.
Hogyan definiálod a hangerőt? A hanganyag peak-je? Vagy legyen a négyzetes középérték átlaga? Valamiféle átlagteljesítmény?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ha az egyszerű megoldás érdekel, technológiai eszmefuttatás nélkül,akkor mp3gain és a hozzá való frontend (easymp3gain, qtgain, stb...)
Elemzi a hangfálj adatait és újrakódolás nélkül emeli a hangerőt, átírja az értékeket. Tud album módot is, ekkor az összes hangfálj értékeit figyelembe veszi.
A hangerő elemzésnél figyeli, hogy torzítani fog-e, erre külön engedélyt kell adni, hogy átléphesse.
https://a.fsdn.com/con/app/proj/easymp3gain/screenshots/163028.jpg/max/…
Köszi. Igen már célbavettem mint egyik lehetséges megoldás. Köszönhetően több hozzászólásnak, most már tudom mennyire fontos, hogy ne legyen újrakódolva.
Még nincs aláírásom.
Ez biztos? Mert nekem úgy tűnik, az mp3 azzal tud trükközni, hogy kidobja a spektrum felső részét, azaz csinál egy fft-t, majd a magas frekvenciákhoz tartozó együtthatókat kidobja, vagy, ha úgy jobban tetszik, nullává teszi. Ha viszont fft együtthatókat tárol, akkor van lehetőség a tömörítettség állapotában is a hangerő változtatására, hiszen a különböző frekvenciához tartozó együtthatókat meg lehet szorozni ugyanazzal az értékkel. Ebben az esetben nem kell idő tartományba transzformálni a hangot ehhez. Persze csak egy vélelmezés részemről, hogy frekvencia tartományban tárol az mp3, nem néztem ennek utána.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
lehet ezt maskepp is csinalni, nem kell kodolgatni. persze nem lesz altalanos megoldas.
https://wiki.slimdevices.com/index.php/Mp3tag#Displaying_Replay_Gain_In…
for file in *.wav; do sox "$file" "n_$file" norm -0.1; done
izé
Ez minden wav fájlt ugyanarra az egy és azonos hangerőre állít be? Köszi, hogy alternatívát is adtál az ffmpeg mellé.
Még nincs aláírásom.
A probléma, h egy számnak nincs hangossági értéke. Mit keresel peak-et, vagy avg-t? Természetesen lehet állítani a hangerőt, csak azt nehéz automatizálni, hogy több számot azonos hangerőszintre hozzon (youtubenak sem sikerül). mp3nál meg figyelni kell arra is h ne legyen további veszteség a formátumból adódóan!
"antiegalitarian, antiliberal, antidemocratic, and antipopular"
Köszönöm a hozzászólásokat. Külön köszönet mauzi-nak, és Rhiannon-nak akik konkrétumokkal tudtak szolgálni.
Úgy néz ki, nem jutok itt dűlöre, akkor majd egyedileg kikisérletezem, hogy melyik ffmpeg attribútum változtatása jelent az én fülemnek hangerőváltozást. Utánap pedig kendácsolok valami szkriptet ami egyesével kiszedi a fájlokból annak az attribútumnak az értékét és minta fájlban lévő érték különbségével majd megtoldom. Aztán majd lesz valami.
Még nincs aláírásom.
Szinte minden player tud normalizalni hallgatáskor, az nem lenne jó neked?
Érdemes amúgy összevetni a nálad lévő mp3-at az eredeti losslessel is hallásra pl Tidal-on meghallgatva. Objektiven meg pl Audirvana eleg jo erre, a free trial idő bőven elég kísérletezni, bár lehet ha mp3-at adsz neki megsértődik ;)
https://help.audirvana.com/en/support/solutions/articles/202000050820-h…-
Audacious-t használok. Észrevehető hangerőkülönbségeket tud produkálni, azért lehet, hogy nem a program hibás benne. Rugalmas vagyok, el tudom képzelni.
Még nincs aláírásom.
https://manual.audacityteam.org/man/macros.html
Ajánlom magamnak és azoknak akik rajtam kívül érdeklődnek a témában:
How to Normalize Audio Files in Linux
Nem egy bölcsek köve, de elindulásnak talán elég.
Még nincs aláírásom.
Azzal legyél tisztában, hogy az itt ismertetett megoldások között van olyan, ami újrakódolja a fájlt, és ez minőségromlást jelenthet. Nem mindegyik, de néhány, pl. Audacity.
A másik, hogy ezt a normalizációt nem a fájlban kéne megoldani, hanem lejátszáskor. Kulturáltabb megoldás. Mert mikor normalizálsz egy mp3 fájlt, akkor mihez normalizálód fájlszinten? Nem fogod látni, hogy mikkel együtt fogod hallgatni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nham, ez egy tipikus nyúlüreg :) Erre érdemes rászánni a 10 percet: https://www.youtube.com/watch?v=nOzZKEWJ5wk
Ha kotorászni akarsz egy fájlban, hogy hogyan van elbökve: https://www.youtube.com/watch?v=Sdv87NzbYnw
Az mp3gain tud hangerőt változtatni újratömörítés nélkül. Illetve az Mp3DirectCut is ilyen, az vágást is tud, de hangerőmódosítást is, szintén újrakódolás nélkül, így nem lesz minőségromlás. Azt nem írtad, hogy milyen OS-hez kell.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
loudgain
Ez nem olyan egyszeru, mint amilyennek hangzik (pun intended).
Az, hogy mekkorak a jelszintek, vagy a hangnyomas, nem feltetlen korrelal azzal, hogy milyen hangosnak hallasz valamit.
innen indulnek: https://en.wikipedia.org/wiki/LUFS
https://github.com/slhck/ffmpeg-normalize/blob/master/README.md
Kifejezetten szórakoztató olvasni, amikor az MP3-at úton-útfélen elavultazó, temető, kőkorszakozó fősodor teljes fogalmatlanságáról tesz tanúbizonyságot, mp3-at mp3-ba (vagyis először PCM-be, aztán újra mp3-ba, valami default szar bitrátával) konvertáló parancssorokat nyomatnak be ide. 🤡 Miközben a legkiforrottabb, legszélesebb körben kompatíbilis, legsokszínűbb hangformátum, amire bőven az ffmpeg-en kívül is elérhető egy csomó specifikus tool.
Az MP3 szabványos megoldása erre újratömörítés nélkül a ReplayGain, aminek beállítására számos alkalmazás létezik. Emellett maga az MP3 szabvány, fix ReplayGain értéken kívül is hordoz a hangerőre vonatkozó információt, utóbbit MP3 editorokkal lehet módosítani.
MP3Gain (Linux: mp3gain, easymp3gain-gtk vagy easymp3gain-qt) és mp3DirectCut (Windows, de Wine-nal is jól fut) alkalmazásokat ajánlom. mp3DirectCut egyes kijelölt részek (vagy a teljes anyag) hangerejét is képes módosítani újratömörítés nélkül, fade in - fade out -okat is bele tud rakni.
Ha MP3 (vagy bármilyen más, veszteségesen tömörített hang)fájlokat módosítasz, mindenképpen próbáld meg megúszni az újratömörítést!
Azt még tegyük hozzá, hogy a hangerő és a szubjektív hangosságérzet két külön dolog - hiába állít minden hangfájt egy adott referencia jelszintje (mondjuk -0.1dB), ha a dinamika szintek eltérnek. Ha pedig a dinamikába belenyúl (kompresszál), akkor nem mindegy mennyire, hogyan csinálja, de akkor sem lesz egységes az eredmény, viszont lesz egy rakat szarul szóló, tömörített hangfájlja, ami csak fejfájást okoz, zenei élményt nem.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Lehet, hogy én bénáztam, de eddig nem sikerült algoritmikusan azonos hangerővel szóló zenét legyártanom.
Még wav fájlokkal sem, az mp3 itt lényegtelen. Pedig wav fájlt minden majom képes kezelni.
Szóval lehet, hogy gyorsabb lenne kézzel beállítani a kívánt szinteket, bár megértem hogy 300 számnál ez mondjuk problémás.
Csak 160 darab, ez persze növekedhet. Az is elég, ha csak körül-belül ugyanúgy szól. Nem vájtfülüek számára szóló zenei élmény kell, hanem csak szimpla zenehallgatás. Háttérzene.
Még nincs aláírásom.
Próbáld ki, nekem nem sikerült. Szarabb lett mind, csak másként. De ha találsz jó megoldást, akkor írd le.
Erre a problémakörre meg a ReplayGain-en belül a külön Track Gain-t és Album Gain-t találták ki, ami egymáshoz képest hozza egy szintre az egyes trackek hangerejét (nem dinamikáját!).
Érdemes inkább utána olvasni, próbálgatás előtt.
https://en.wikipedia.org/wiki/ReplayGain#Track-gain_and_album-gain
Mivel minden egyes hangfájlnak eltér a dinamika szintje, ezért először mérni kell, majd a mérés eredményétől függően különböző mértékű dinamika kompressziót kell alkalmazni - a normalizálás nem alkalmas erre, hiszen az nem változtatja meg a dinamikai arányokat, kizárólag a hangfájl leghangosabb részletét alapul véve igazítja a hangerőt beállított jelszintre a dinamika arányok megtartásával. Mivel a dinamika kompressziót egy végleges belenyúlás az eredeti dinamika arányokba, én nem javasolnám ezt a megoldást, mivel véglegesen elrontja azt, amit a hangmérnök kikevert, ráadásul ami egy bizbasz fülhallgatón még lehet hogy nem drasztikus, az egy jobb hangcuccon már halkgathatqtlan eredményt produkál! Ne tedd tönkre a gyűjteményt, ha semmiképpen nem tudod nélkülözni a loudness-élményt, akkor használj valami külső eszközt, effektet, amit legalább igény és hangulat szerint lehet állítgatni/kikapcsolni!
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Minden jó tanácsot szívesen fogadok, köszönöm. A dinamika kapcsán azt írtad: "én nem javasolnám ezt a megoldást". Na konkrétan melyik volt az? Elnézéstt az értetlenkedés miatt, de most tényleg nem tudom mire gondoltál pontosan.
Még nincs aláírásom.
Mondom, nyúlüreg.
"dinamika kompressziót kell alkalmazni ... én nem javasolnám ezt a megoldást" -- ez az, ami "elrontja" azt, amit a Szent Hangmérnök megcsinált. Az már a te hibád, ha nem Nagra + Nautilus rendszeren hallgatod.
Alapvetően nem derül ki, hogy pontosan mi a problémád. Valószínűleg a dinamika/loudness az. Ha nem világos a volume - loudness különbség: https://hup.hu/comment/3138811#comment-3138811
Ha a loudness a probléma - azaz a Szent Hangmérnök nem nyomorította meg annyira a mixet, hogy hallgatható legyen laptopon/tableten/telefonon is -, akkor neked kell ezt megtenni. Ez viszont tipikusan kínkeserves nyomor. Kis szerencsével a lejátszód - pl. Pulsar - tud valami hasonlót (loudness/compressor), rossz esetben át kell kódolni a meglévő fájlokat és vagy valami automata (manapság AI) tekerget rajta és lesz ami lesz, vagy te magad, fülre, és lesz ami lesz.
Ideális esetben fájlonként lehetne a beállításokat tárolni, így a különbözőképp mixelt hanganyagok közelebb kerülhetnek egymáshoz.
Ha kompresszorozni akarsz, akkor kompresszorozz a lejátszóval, ne a hanganyagokat rontsd el, mert más hangeszközön úgyis máshogy fog szólni. Keress olyan lejátszót, ami tud ilyet és meg van oldva a dinamikaproblémád.
Mai tárolási kapacitás árak mellett akár megtarthatja az eredetit és a kompresszáltat is. Khm, legfeljebb egy kicsit bloat lesz, de működik :-)
Szokásos, lokális optimumokat kereső, csőlátású befektetőlogika.
Egyfelől, OP azzal kezdte, hogy neki MP3-ai vannak. Ezeket semmi értelme újrakompresszálni. Csak rosszabb lesz.
Másfelől, igényeit tekintve, inkább a lejátszó felől kéne megközelíteni. Számos kiforrott, funkciógazdag lejátszó létezik, PC-re, okostelefonra, amiben van dinamikakompresszor.
Szóval, az eredeti MP3-at kéne megtartani, és lejátszási oldalon "módosítani".
Azt, hogy szétkompresszálod a hangfájlt! Ha már erre van ingerencia, akkor külső kompresszor megoldást érdemes használni, így megmarad az eredeti anyag, ami később továbbra is bármin lejatszható, meghallgatható lesz. Ha megváltoztatod a hangfájlt, onnan már nincs visszaút (ez vonatkozik az újratömörítés okozta károsodásra is).
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Természetesen a kimenet egy másik fájl egy másik könyvtárban. Aztán ellenőrzöm az eredményt, ha nem felel meg akkor eldobom.
A jó hír, egyelőre még nem csináltam semmit. Csak tájékozódom és figyelem a hozzászólásokat is. Az is lehet, hogy végül bele sem fogok, azok alapján amit eddig olvastam.
Még nincs aláírásom.
Van preferált MP3-lejátszód? Milyen platformon, milyen eszközön szeretnéd lejátszani?
Manjaro, Audacious. Szívesen fogadok javaslatokat más lejátszóra, de nem garantálom, hogy váltani fogok. :)
Még nincs aláírásom.
Abban ott is van kapásból a Dynamic Range Compressor.
Aztán Services -> Plugins -> Effect -> Dynamic Range Compressor, bekapcsolod.
Itt van hozzá valamennyi magyarázat: https://redmine.audacious-media-player.org/boards/1/topics/1374
Kísérletezz vele, több zeneszámon is.
Ha nem válik be, akkor ajánlom még a ladspa pluginokat, amiket bele tudsz tolni pulseaudio-ba vagy pipewire-ba, és szerintem arra is tudsz gyártani valami filtert, hogy csak akkor működjenek, ha audacious-tól kapják a stream-et.
https://docs.pipewire.org/page_module_filter_chain.html
Tudomásom szerint régen maga az audacious is tudott LADSPA hostként működni, de ezt lehet, hogy kiinnoválták™ belőle, amikor volt a félresikerült GTK3-bloat átállásuk, amit aztán a Qt5-bloat, később a Qt6-bloat átállás követett.
Köszi!
Még nincs aláírásom.
Elméletileg igazad van, de gyakorlatilag akkor is előnyben kell részesíteni azokat az eszközöket, amik nem tömörítenek újra. Ha azokkal lehetséges elérni a kívánt hangerőt, akkor az egy jobb kompromisszum, mint a tényleges hangerő növelése, de újratömörítéses minőségvesztéssel együtt.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Amikor kölyök voltam számított, hogy egy 650 mbyte-os CD-re hány mp3 fér fel.
Manapság, ha fogod az egész mp3-at és át nyomod wav-ba azzal sem lesz nagy bajod.
Rohadtul senkit sem érdekel a bitráta, a 320k-t csak azért használjuk, mert nincs magasabb.
Magyarul: wav-ba konvertálsz, normalizálod és ha meghagyod wav-ként, akkor nincs veszteséged. Csak akkor van, ha újra veszteségesen tömörítesz.
Egy előttem szóló már említette ezt az apróságot.
Vájtfülűeknél számít. Nekem nem okoz lelkiismereti problémát a 320k-s ide-oda tömörítés, bár tudom, hogy illetlen dolog.
30 évvel ezelőtt egy idióta haverom mindent 96kbps-sel tömörített, mert minden zenéje egy CD-re felfért. Na az sok volt, az egész válogatása ment a kukába.
Az mp3 sose lesz elavult, ahogy a jpeg meg a zip se. Főleg úgy van nagyon sok előnye, hogy minden támogatja (eszköz, platform, szoftveres megoldások), és a szabadalom is lejárt róla, nem kell hozzá többé licenc, és kisebb komplexitású kódek. Írom ezt annak ellenére, hogy én nyugdíjaztam, csak olyan eszközre vagy alkalomra tömörítek mp3-ba, mikor valaki ezt kéri tőlem, vagy legacy felhasználásra lesz, ilyenkor a legújabb (jelenleg 3.100-as) LAME encoder-t használom VBR0 (-V0) vagy 320kbps CBR presettel (-b320 -q0). Tovább léptem újabb kódekekre, Vorbis (-q8-10, helyigény függvényében, ezt 44,1 kHz-es anyagokra használom), Opus (--bitrate 256-320 kbps, helyigény függvényében, 48, 96, 384 kHz-es anyagokra), de ha a helyigény nem annyira számít, dobtam már a lossy formátumokat, és FLAC-ot használok helyette (-8 -ep paraméterekkel). Ott lenne még az mp3 készítőinek a munkája az AAC, de ugye az még nem teljesen szabadalommentes (van olyan ország, ahol még az AAC-LC szabadalom nem járt le, bár még pár év és mindenhol lejár), meg a legjobb tömörítők (Apple, Nero) zárt kódúak, így igyekszem bojkottálni, zárt formátumot elvből nem támogatok.
Egyébként elméleti, mert az újabb kódekeknek (AAC-HC, Opus, stb.) csak alacsony bitrátán van előnyük (32-128kbps), ahogy elérünk a 256 kbps környékére, ott már minden codec úgyis transzparens. Esetleg még amiben az újabb kódekek többet tudnak, az a több sáv tömörítése, hézagmentes lejátszás, high-res támogatása, stb., bár nekem a legtöbb anyagom továbbra is 44.1 kHz-es 16 bites sztereo.
Az mp3DirectCut-nak volt egy natív FOSS változata is, valami mp3splt, vagy mi a rák, csak a nevére nem emlékszem, többször átnevezték a projektet. Így nem feltétlen kell Wine-hoz nyúlni, azt csak legvégső esetben érdemes megtenni. A legtöbb mindenre van már jól használható FOSS alternatíva.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ebben nem értek egyet. Kijelenthető, hogy manapság a bitráta irreleváns. Magyarul elfogadható tömörítésű lossless codec kellene.
Néhol még releváns, mert mobil eszközökben fix Flash-alapú tároló van, amit nem is lehet már bővíteni (telefonok, táblagépek). PC-nél valóban nincs már értelme. A másik, ahol releváns, azok a szűk sávszélességre szabott online stream-ek, digitális rádió, stb..
Egyébként definiáld, hogy mi az elfogadható. Semmi nem tömöríthető a végtelenségig, a tömörítés görbéje aszimptotikusan limitált, egy szinten túl egyre irreálisan hosszabb tömörítési idő vagy irreálisan nagyobb komplexitási szint/energia bevitele kell, hogy a tömörítés javuljon egy nagyon hajszálnyit, ergo egy ponton túl nem éri meg. Olyan ez, mint a fénysebesség elérése. Mindenkinek más kbps és tömörítési sebesség lesz elfogadható. A FLAC egy kellően jó kompromisszum, igen, vannak, amik jobban tömörítenek pár %-kal, de azok sok %-kal lassabbak is, meg kevesebb eszköz támogatja őket.
Ez nem csak audiónál, videónál van így, mindennek a tömörítése ilyen. Pl. a mostani rekorder tömörítők (pl. paq8, zpaq, cmix, nncp, tensorflow, stb.) brutálisan lassúak, sok közülök ilyen 24-48 órán át tömöríti azt, amivel a „normál”, használatban elterjedt tömörítők max. néhány perc alatt végeznek ugyanazon a hardveren, közben irdatlan RAM-ot vagy VRAM-ot esznek gigaszám, és csak alig pár %-ot faragnak le a tömörített fájl méretéből, így a gyakorlatban csak elméleti rejszolás, nem éri meg. Én ezért is preferálom a zstd-t, az sebességre van optimalizálva, és emiatt nem tömörít olyan jól, mint egy xz, 7-zip, vagy más LZMA2, PPM tömörítő, de jobban tömörít, mint egy pkzip, gzip, lz4, brotli, de sebességben ver mindent (kb. 10x sebességgel tömörít sok megoldáshoz képest), és a jobb tömörítőktől is csak néhány %-kal marad el.
Egyébként a legjobb tömörítő szerintem a nanozip volt, ami jobban tömörített, mint az elterjedt tömörítők, de még nem volt olyan brutális a kompexitása, mint az extrém tömörítőké, lassúcska volt, de még kibírható. Viszont a készítője meghalt 11 éve agydaganatban, és sikeresen magával vitte a kódját a sírba, ami sose volt nyitott, jár érte a fejére a simi. Azóta nem volt karban tartva a kód, megmaradt Windows only, legacy binárisnak.
A médiatömörítés csak annyiból speciális, hogy ott valós időben kell megvalósuljon legalább a kikódolásnak, nem ér rá 24 órákat, annyit nem fog rá senki várni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Csak úgy kvázi blogposztként írom ide, hogy pont ma volt szükségem az mp3DirectCut-ra. Ilyenre nem volt példa már vagy 6-8 éve, hogy épkézláb feladathoz, ami nem csak egy teszt volt, kellett futtatni egy Windows only programot, általában mindig találok linuxos alternatívát, de ez valóban jól fut Wine alatt. Egy YouTube-ról letöltött aac fájlt kellett veszteségmentesen megvágni, mert a videó készítője nem tudni mi okból betoldott egy 16 másodperces szünetet az audió elejére. Ezt a konkrét programot utoljára valami 18 éve használtam, de most megint nagyon jó szolgálatot tett.
Sajnos Linuxra nincs olyan tool, ami tud aac-t veszteségmentesen vágni. Az mp3splt tud mp3-t és ogg Vorbist, de itt kifújt. Pedig már az aac kódekre is lejárt a szabadalom, de nincs még hozzá ilyen lossless edit megoldás. Nem is értem, hogy az mp3DirectCut-ot miért nem portolja valaki Linuxra, eleve FOSS, így még az se akadály, hogy ne lenne meg a forráskódja, vagy a licenc ne lenne megengedő ezen a téren.
Jobb lett volna természetesen, ha van ilyen szoftver, natívan Linuxra, főleg, ha CLI vagy TUI, de hát az élet sose olyan egyszerű, hogy minden legyen, de még minimalista is legyen. Az túl szép lenne, hogy igaz legyen.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez nem jó?
ffmpeg -i hosszu.aac -c copy -ss 16 rovid.aac
Ez tud frame-határon vágni? Mert a doksiból nem derül ki:
-ss position (input/output)
When used as an input option (before "-i"), seeks in this input file to position. Note that in most formats it is not possible to seek
exactly, so ffmpeg will seek to the closest seek point before position. When transcoding and -accurate_seek is enabled (the default),
this extra segment between the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek
is used, it will be preserved.
When used as an output option (before an output url), decodes but discards input until the timestamps reach position.
position must be a time duration specification, see the Time duration section in the ffmpeg-utils(1) manual.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Kedves drága parancssorhuszárom, ismerkedj meg a Linuxon is működő megoldással.
MP4 konténerbe való copyzás után működik az ffmpeg-nél advanced-ebb MP4Box.
Youtube-ról letöltött hangsávok esetén javasolt még az MP4Box -ipod lefuttatása az interleave-elés miatt, így régebbi/hardveres lejátszóknál nem lesz probléma a seekeléssel. Illetve, ha a fenti ffmpeg parancs nem jól helyen vág, akkor érdemes először meglépni az interleave-elést.
Annak azért örülök, hogy elismerted, hogy nincs Linuxra a Windows-ossal egyenértékű natív GUI-s alkalmazás, mert valóban nincs. Ugyanakkor ma újabb szöget vertünk be a "Raynes mindent megold Linux terminálban" feliratú koncepcionális koporsódba, mert ha akartad volna, megoldhattad volna terminálban, de neked kényelmesebb volt mp3DC-ban. Ezek után nettó bohóckodás, amikor azt írod, hogy nekem át kéne állnom a paranccsorosnál jóval hatékonyabb GUI-s appokról terminálosakra, csak mert azok FOSS, meg frissülnek, meg stb. idealizmusok.
vicces, mikor hajbi szerint a gui bloat nem szamit :) hat mi lesz igy a vilagunkkal? :D
GUI bloat? Az mp3DC kevesebb CPU-t és memóriát zabál, mint az ffmpeg és kisebb helyen is elfér.
Nem a GUI teszi bloat-tá az appot, hanem a bloated módon implementált GUI. Az mp3DC tipikusan azoknak az alkalmazásoknak a körébe tartozik, amik GUI-s mivoltuk ellenére sem bloat-ok. Mondok még párat: Total Commander, IrfanView, Notepad++, MPC-HC, WinAmp stb.
a guinak kell extra kod, cpu, ram, gpu... ezzel hiaba vitatkozol. az ffmpeg bloat? aha, nezd meg a funkcionalitasat az mp3lofaszcuthoz kepest, haver! :)
csak szolok ;) hint: MP4 and M4A to AAC by linked ffmpeg.exe #veletlenaligha...
https://a.te.ervelesi.hibad.hu/lenyegtelen-konkluzio
Nem ezzel vitatkoztam.
Adott feladattól függ. Egy MP3 vágásra az ffmpeg bloat-abb, mint az mp3DirectCut, tekintve, hogy az mp3DirectCut kevesebb erőforrásból sokkal több, kényelmesebb funkciót és GUI-t is ad erre a feladatra.
mp3DirectCut 1,25 GB-os, 256 kbit/s 11:40:26 hosszú MP3-at 55 másodperc alatt, 2% CPU és 7,5 MB memóriafogyasztással frame copy-zik. A Linuxos ffmpeg ezzel szemben 1 perc 7 másodpercet szarakodik ugyanezzel az MP3-mal, 18 MB memóriafogyasztással, sőt közben mindkét magot 100%-on felzabálja. Szóval igen, MP3 vágásra az ffmpeg bloat-abb, pláne, hogy parancssoros, tehát semmi nem indokolja a majdnem 2x-es memóriazabálást.
A funkcionalitás nem kifogás a bloat-ra, főleg ha adott feladat elvégzése annak a funkcionalitásnak 1%-át igényli. Úgy kell összerakni a szoftvert, hogy a kihasznált funkcionalitásnak megfelelően fogyasszon erőforrásokat. Az ffmpeg ilyen szempontból egyébként rendben van. Főleg, hogy libként is lehet linkelni, akár kizárólag csak azt a bináris kódrészletet, amire szükség van belőle. Viszont az mp3DirectCut hatékonyabb nála.
A funkcionalitás nem kifogás a bloat-ra > de. :)
ezt ignoraltad, kedves baratom! "hint: MP4 and M4A to AAC by linked ffmpeg.exe #veletlenaligha..." jahogy ha kell funkcionalitas, akkor mar er linkelni a bloatot? :)
MP3 vágásra az ffmpeg bloat-abb > arra nem gondoltal, hogy az ffmpeg mast csinal? ;) hint: de :)
Nem az, főleg nem, ha van azonos funkcionalitást adó, hatékonyabb megoldás. Eszközt feladathoz választunk és itt a feladat egy AAC hangfájl megvágása. Erre az ffmpeg-nél van egy sokkal több funkcionalitást adó mp3DirectCut, ami még erőforráshatékonyabb is az ffmpeg-nél.
Nem ignoráltam, de feleslegesnek tartom az ffmpeg-et ffmpeg-hez hasonlítani, csak mert te fogalmatlankodsz. Ha MP3-mal dolgozol, akkor az mp3DirectCut egyértelműen megveri az ffmpeg-et teljesítményben, funkcionalitásban pedig szarráveri a GUI-nak köszönhetően. Azt viszont jó lenne nem elfelejtened, hogy az mp3DirectCut alapvetően és elsődlegesen egy MP3 editor.
Nincs linkelve a bloat, félreérthető a szövegezés. A 132 kB-os mp3DirectCut-nál 500x több helyet elfoglaló ffmpeg.exe-t be kell tallózni neki Settings -> Decoder alatt és/vagy a libfaad2.dll-t berakni mellé, ha szeretnél AAC hangsávokat demuxolni/lejátszani tudni. Sima vágáshoz egyik se kell, azt az mp3DirectCut natívan csinálja AAC esetben is. Ja és azt is hatékonyabban, mint az ffmpeg. ;)
Nézzük csak...
Régi szép vitáinkra való nosztalgikus tekintettel letöltöttem (magánmásoltam) a hangsávját ennek a Youtube "videónak": https://www.youtube.com/watch?v=Ktc23EfaMHg
Ez egy 7 óra 44 perc 34 mp-es AAC audiofájl. Az mp3DirectCut 21 másodperc alatt ledarálta framecopy-val az egészet egy másik AAC fájlba, közben 8,2 MB memóriát és 2% CPU-t zabált (gyakorlatilag csak I/O műveletezett). Mindeközben az ffmpeg 2 magot 100%-on és 64 MB memóriát felzabálva csinálja meg ugyanezt 34 másodperc alatt. Ha csak egy magot zabálhat fel, akkor a 34 másodperc 1 perc 27 másodperc lesz, miközben az mp3DirectCut CPU affinity-jét állítva 1 magra, pontosan ugyananúgy 21 másodperc alatt végez (mondom, csak I/O műveletezik).
Igen, dorsyka, ez bloat, ráadásul annak egyik iskolapéldája. Most pedig képzelj el egy olyan hangvágó/framecopy-zó alkalmazást, amibe ffmpeg-et integráltak, és tádámm, így születik a bloatware.
Erre neked kellett volna gondolnod, mielőtt egyáltalán egy síkra hozod a kettőt.
1996-ban erdekelt, h valami 7.5 8 16 vagy 60 MB RAM-ot eszik. 2025 van, a cpu cache-em 36MB :) (ez is lassan 5 eves!)
almat hasonlitgatsz kortevel, az ffmpeg recode-ol. FYI.
https://a.te.ervelesi.hibad.hu/szemelyes-ketely
Nem csak recode-ol. Megoldható vele a vágás, mint feladat, csak erre szuboptimális és bloat.
Nincs itt semmilyen érvelési hiba, igaza van. Mondom ezt úgy, hogy én is kényes vagyok a memóriafogyasztásra, de ilyen médiafájlokkal való műveletvégzés mindig is memóriaigényes, mivel óriásiak ezek a fájlok, így a lejátszó, konverter, transzkóder, vágóprogram 8-60-100 megás foglalása már nem tétel afölé, főleg, hogy minden releváns gépben van több giga RAM, még a te múzeális vasadba is tettél 4 giga RAM-ot. Így 7,5 vs. 60 mega RAM még nálad sem kottyan meg, főleg, hogy nem minden nap framecopy-zol 7 órás audiófájlokat.
Mondom, te azért méred lassabbnak az FFmpeg-et, mert 1) muzeális vason, 2) olyan muzeális OS alatt használod, amire nem tervezték, ennek ellenére hálás lehetnél, hogy fut, működik. Ez mind egyéni szocprobléma, ha én mérném, nálam fordítva lenne, az Mp3DirectCut-nak lenne több a CPU/memóriafogyasztása, de nem a szoftver miatt, hanem a Wine-réteg miatt Linuxon. Ez ilyen oda-vissza érvelgetős játék, nem érdemes rajta lovagolni. Én sem tettem, mert csak hálás lehetek a Wine-osoknak, hogy ez a windowsos szoftver is hibátlanul fut egy olyan rendszeren, amire nem tervezték, ennek oltárán simán elnézek itt-ott egy kis bloatságot. Nem érzem képmutatásnak, jelen esetben teljesen indokolt.
Csak akkor vagyok a bloatság ellen, ha indokolatlan, meg csak a soydev-ek felesleges bonyolítása, 50 köztes rétegezése okozza, akkor nekem is ráng tőle a szemem, ha nem muszáj, nem is vállalom be az ilyet, nem véletlen nem használok Electron, Java alapú, vagy konténerizált csomagformátumos (Flatpak, Snap) appokat a mindennapokban. Néha napján kivételt teszek, amikor kell valami ritka, spéci megoldás, pl. nagy ritkán az egyik ismerős miatt kell futtatnom Signal-t, ami Electron app, meg néha használok ritkán futtatandó programokat, amiknél nem akarom, hogy napi 50x frissüljenek az Arch repókból, így pl. ha nagy ritkán kell, a LibreOffice-t, MuseScore-t, Goldendict-et Appimage-ből használom, illetve néha a Double Commandert újabb verzióit is ilyen formátumban tesztelem. Illetve nagy ritkán kell valami Java-alkalmazás, ez is szökőévente egyszer, TuxGuitar (Guitar Pro 2-5 fájlok olvasására), AbevJava, néhány nagyon ritka sakk-GUI, vagy valami androidos-javás visszafejtő tool miatt kell futtatni. Ugyanez van a Wine-os programokkal, igyekszek nem windowsos programot használni, mindenre a linuxos, 64 bites natív megoldást használom, ha létezik. Ez alól is kevés kivétel van, néha tesztelek aac tömörítési minőséget, sebességet Apple QAAC-vel, de az csak teszt, meg most kellett ez az Mp3DirectCut. Kényszerű kompromisszum néha, de még így is jobb, mint feleslegesen ilyen hülyeségekre több gigás Windows telepítést tartani, meg átbootolással vergődni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Helyesen: Nincs itt semmilyen igaza, csak érvelési hibája.
Ócska szar közhelyes kifogás. Pont, mint a "bloat, mert multi-platform".
Pont az ilyen óriási™ fájloknál jönnek ki a legtöbb implementációs bloat és mutatkozik meg, hogy ki a valódi fejlesztő a gáton, meg ki a szójalattét kortyolgató framework-láblógató a babzsákon. :P
Nincs muzeális vasam. Mai igényeket, használati eseteket, a mindennapi munkámat kiszolgálni képes gépem és rendszerem van.
Nem mondtam, hogy megkottyan. Azt mondtam, hogy bloat. Amiben igazam volt, mert létezik nála legalább egy sokkal hatékonyabb implementáció.
Hálás is vagyok azoknak, akik backportolják az ffmpeg-et Windows XP-re. Kicsit többet tesznek a világ jobbá tételéért, mint te, aki beállsz a frissítésmániáddal a birkasorba.
Csakhogy szar a hasonlatod, mivel az ffmpeg-nek nincs semmiféle rétege Windows XP-n, hanem natívan fut rajta. De mondom még egyszer: megnéztem Linuxon is ezen a hardveren (Linux Mint 22, ffmpeg 6.1.1), eredmény ugyanaz. Linuxon ráadásul valamivel több memóriát zabál fel a modern™ OS™ 64-bitje miatt. 🤡
Akkor ne tedd! 🤡
Én is hálás vagyok az ffmpeg-eseknek, az XP-re backportolóknak még inkább, de eszemben sincs olyanra használni a cuccukat, amire Linuxon és Windows-on is szuboptimális.
Én meg annak érzem.
Minden bloat indokolatlan.
Ez van, tévesen ítélsz meg dolgokat. A 64 bites kód. pl. igaz, hogy több memóriát foglal, de sok esetben mégis gyorsabb, mert 64 bites módban több és nagyobb CPU regiszter áll rendelkezésre, meg 64 bites regiszterekben össze tudsz vonni több kisebb adatot és egyszerre tudsz rajta egy utasítást végrehajtani, így egy füstre lezavarod azt, amihez 32 biten 2 utasítás, 16 biten 4 utasítás kellett. Nem minden kódon gyorsít, de ezek a médiakonvertálós mókák pont az a műfaj, ahol szokott számítani.
Nem minden bloat indokolatlan. Ha pl. egy szoftvernek tényleg annyi funkciója van, vagy pl. platformfüggetlen köztes rétegeket használ, akkor egyes esetekben védhető, indokolt lehet, valamit valamiért cserében alapelv mentén.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
hagyd, mar tobbedjere bizonyitja, hogy
nem ertinem akarja erteni - mert trollkodik - tobbek kozt a hatekonysag micsoda es hogyan szamoljuk, kihagyja a kepletbol az elvegzett munka mennyiseget :) ha tizezren allnak ele es szembesitik vele, akkor sem fog leszakadni a fejeben terjengo butasagrol. mert akkor a mar nagykoru laptopja es ikszpeje elverzik. csunyan. o mar csak ilyen :)Nincs mit tévesen megítélni. Ami kevesebb CPU-t, memóriát eszik és kevesebb idő alatt végez, az egy hatékonyabb implementáció, míg a nála 100x több erőforrást zabáló implementáció bloat. Függetlenül attól, hogy hány bites, meg milyen OS-en fut.
Igen, pl. az ffmpeg-en nem gyorsít. 🤡
Ez meg egy tipikus kényelmeskedő, babzsákfejlesztői érvelés. Tudod, azért eszik 300 MB-ot a JS, mert magyarul is megjelenik az oldal, nem csak angolul. 🤡 Igen, van egy feltétlenül szükséges overhead, de azt az ég világon semmi nem indokolja (a bloat mivoltán kívül), hogy ez 200% vs. 2% CPU-ban jelenik meg. Azt pedig kéretik valahogy igazolni, hogy az ffmpeg valóban a multiplatform mivolta miatt zabál ennyit framecopy-nál.
ha ertenel hozza, akkor tudnad hogy egy modern cpun a 100x bloat cucc is gyorsabban fog lefutni, es kevesebb energiat fog enni, mint a 15 eves fosodon \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ha értenél hozzá, akkor tudnád, hogy egy modern CPU-n a 100x bloat ugyanúgy kimutatható és ugyanúgy bloat és semmiféle felmentést nem ad a babzsákfejlesztőknek az, hogy az ő 13. generációs 8 magos 64 GB RAM-os, 1 TB SSD-s csilihardverükön X másodperc alatt lemegy valami. A "megspórolt" energiát pedig már elfogyasztották a bányában a munkagépek, a gyárakban a gyártósorok, a 6000 km-es úton a szállítójárművek.
Ha értenél hozzá, akkor tudnád, hogy nem csak azért fontos a hatékony, optimalizált kód, hogy a 15 éves hardveren gyors legyen, hanem azért is, hogy a modern CPU ténylegesen tudjon energiát spórolni és ne legmagasabb C-state-ben ketyegjen, hanem mondjuk 800 MHz-re underclockolva, akksiról is gyors legyen az implementáció.
multkor mar mutattam hogy nem mutathato ki: ami a te fos cpudon 1 masodpercig fut, az egy modern cpu nehany millisec alatt (ssl kodolas). ugyhogy az a cpu regen megporolta a banyak munkagepeinek, meg gyartosorok energiait. az egyeduli aki energiat pazarol az te vagy, vagyis a fos cpud! \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Mi lenne, ha üres, fogalmatlan, fejlődésmániás mellveregetés és újravásárlásbuziskodás helyett inkább megmérnéd, hány millisec alatt framecopyzik az ffmpeg egy 8 órás AAC stream-et, és közben mennyi CPU-t, memóriát zabál? Én legalább megtettem.
csak ures duma. melyik fajlon, es neked mennyi jott ki az eredmeny?
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Tévedsz. Az FFmpeg semmivel nem lassabb, ha framecopy műveletet végez, és nem tömörít újra, épp úgy pár pillanat alatt megcsinálja ugyanazt. Ez a 7 órás aac fájl is egy kivételes felhasználás, normál esetben nincs értelem ilyen hosszú audiófájlnak, senki nem hallgatja végig, nehéz benne keresni, állandóan oda kell pozicionálni az aktuális részhez.
Ahol az FFmpeg bloatabb, az a kódmennyiség, de az is indokolt. Az Mp3DirectCut csak 3 audiókodeket támogat, azt is csak egy platformon (Windows x86), ezzel szemben az FFmpeg egy nagy gyűjtőprojekt, minden létező audió, videó, felirat, konténer formátumát, ki/bekódolását, transzkódolását, szűrőket, videó/audió bemeneti eszközöket (mikronon, asztal, webkamera, videókamera, stb.), optikai lemezformátumokat, stb. támogat, ráadásul ezt elég sok platformra, architektúrára, GUI sem kell neki. Egy megaprojekt, amire elég sok minden alapul, számos szerkesztő és lejátszóprogram, pl. a VLC, mpv, foobar2000, MPC-BE, Kodi, Handbrake, Kdenlive, stb. erre épül! Már a kedvenc MPC-HC-d is használ belőle kódrészekeket, egyes szűrőket, kódekeket ezzel valósít meg, de még nem teljes egészében alapul FFmpeg-en. Kb. több ezerszer többet tud, és sokkal többrétűbb, mint az Mp3DirectCut, persze, hogy nagyobb a kódméret, forráskódnál és lefordításnál is, de azt is vedd figyelembe, hogy ebből nem minden programfutás során használ mindent.
Illetve FFmpeg-nél csinálhatod, hogy nem minden modult fordítasz le hozzá, úgy sokkal soványabbra lefordítható, de úgy szerintem értelmét veszti az egész, mert pont az lenne a lényege, hogy mindenes szoftver, sok mindenre használható.
Az sem igaz, hogy az FFmpeg-be be kell tallózni akármilyen .dll-t. Lehet elavult WinXP-s implementációnál be kell, de modern platformokon nem kell neki semmit betallózni, használja automatikusan a rendszer dinamikus libjeit, amennyiben azok vannak elég újak, de erről modern rendszeren gondoskodik a csomagkezelő, repókból mindig újítja meg a függőségeket is. Ahogy írtam, modern desktop rendszerekre telepíteni se kell, mert valamilyen lejátszó, szerkesztő, böngésző program ami alap telepítésben ott van a rendszeren behúzta függőségnek, így szinte minden disztrón ott van, egyedül BSD rendszereken nincs (bár Midnight, NomadBSD-n azért ott van), de ott is felkerül, mert vagy az asztali környezet, vagy valamilyen lejátszó program, amit felteszel, húzza be függőségnek. Tehát se a fordítgatásával, se a telepítésével, se a libek betallózásával nem kell foglalkozni. Feltétlenül még a terminált se kell elővenni hozzá, mert épülnek rá GUI-s programok, meg GUI frontendek, a Handbrake is ilyen.
A másik módszer, hogy statikusan linkeléssel fordítod le, akkor sem kell neki semmit betallózni. Ezt nem javaslom, főleg a te gépeden, mert annyi millió kódsor, hogy az FFmpeg még combosabb gépeken is fordul vagy 20 percet, gyengébbek, de még aktuális gépeken is fél-egy órát. A te muzeális vasadon kb. 1-2 nap is lehet. De ez az a kategória, amit még a Gentoo-felhasználók se forgatnak minden nap, de nem is kell, mert nem jelenik meg belőle túl sűrűn új verzió.
Azt is vedd figyelembe, hogy az FFmpeg modern rendszeren skálázódik akárhány szálra, magra, meg támogat új utasításkészleteket (SSE 4.2, BMI, AVX, AVX-2, AVX-512, stb.), ha azokkal fordították (gcc -march=native), az Mp3DirectCut kötve hinném, hogy ezt szintén tudja. Igaz rászorulva sincs, mert frame-határon dolgozik, nem kódol semmit újra, inkább csak I/O másol-írogat. Így egy modern gépen futtatva nem lenne ez a 13 másodperces különbség.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nem is állítottam, hogy újratömörítene, tehát nem tévedtem. A framecopyra eszik sokkal többet, mint az mp3DirectCut.
https://a.te.ervelesi.hibad.hu/nem-igazi-skot
Persze, nyilvánvalóan csak annak van értelme, amit te csinálsz egy audiofájllal. 🤡 Mert nem szoktak felrakni egész albumokat egyben, így tehát nem valós feladat, hogy ki kell vágni egy számot egy másfél órás hanganyagból. 🤡🤡
Az ffmpeg a framecopyzásnál CPU- és memóriabloat, mivel az mp3DirectCut töredék (század annyi) erőforrásból megcsinálja.
Captain Obvious strikes again. Ettől még a framecopyzása lehetne hatékony, de nem az. Valóban nem ez az elsődleges célja, de nem is ad felmentést a bloat-ra. Pontosan ugyanúgy bloat, mintha csak 3 kodeket tudna.
https://a.te.ervelesi.hibad.hu/hamis-okozat
A dekódolási képességeinek hatékonyságát nem vitattam. Framecopyzásban bloat. Nem mellesleg a lavfilters (amit az MPC-HC használ) nem azonos az ffmpeg-gel, hanem egy kizárólag dekódolásra optimalizált library.
Captain Obvious strikes again. Ettől még a framecopyzása bloat marad.
Értőolvasás fail. Az mp3DirectCut-nak kell betallózni az ffmpeg.exe-t és/vagy a libfaad2.dll-t.
Figyelembe vettem, de ettől még a framecopyzása bloat, mert százszor annyi CPU-t és 3x annyi memóriát vesz igénybe hozzá, mint az mp3DirectCut. Nyugodtan megírhatsz még 25 marketingkommentet az ffmpeg-ről, meg dobálózhatsz egyértelmű állításokkal, amiket korábban sem vitattam, ettől még az ffmpeg framecopyzásra bloat marad. 🤡
ne vard el tole hogy megertse mi mindenre is jo az ffmpeg. o csak azt kantalja hogy bloat(tm)!!! :DD
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Framecopyzásra az. Az mp3DirectCut századannyi CPU-ból és harmadannyi memóriából elvégzi ugyanazt a feladatot, rövidebb idő alatt. Más képességeit nem firtattam az ffmpeg-nek.
Persze, nem várom el, hogy megértsd a 3-5 évente újravásárolt csiligéped mögül.
az megvan hogy a framecopy is igenyel feldolgozast, megha az streamet nem is kell dekodolni? persze hogy bloat a fos cpudon, mert semmi gyorsito utasitast nem tud \o/
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
hagyjuk is. fullhd hvec-bol av1-be par wattbol az intel kartyam kb. 350-400 frame/s-kel kodol at, mert benne van a celhardver hozza... :)
Amit ugye újra kellett vásárolni és ha majd jön a H.266, akkor megint újra kell. 🤡
Holott, lehet, hogy egy régi Intel GPU is képes lenne HEVC-t dekódolni erőforrásilag, csak multiék nem hajlandók rá olyan microcode-ot rakni?
ha ertenel hozza akkor tudnad miert lettek ezek a modern h25* kodekek es nem csak bloat(tm)-oznal....
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
nem kellett semmit ujravasarolni, neked sem kene, mert nincs olyan eszkozod, ami ezt tudja. es ha ujravasarolod, akkor sem fogja. bohoc.
nem hajlandók rá olyan microcode-ot rakni? > ezzel a kerdessel ujra bizonyitod, hogy halvany lila gozod sincs mi az a media engine es miert nem csak egy mikrokod kerdese a hardversupport :)
Nem csak mikrokód kérdése, valóban. Ettől függetlenül a GPU ugyanúgy egy RISC processzor, aminek van valamekkora sebessége adott feladat elvégzésére. Lehet, hogy egy 2. generációs Intel GPU nem lenne képes 4K HEVC-t dekódolni, de egy 2K-t elvinne ugyanazon az órajelen, amin egy 4K H.264-et sikeresen dekódol. Elemi műveletekre levetítve nem csinálna mást HEVC esetben sem.
a cpu is tudja dekodolni, encode-olni (igaz 350+ helyett <30 fps-sel, 100% terhelesen, 12 szalon, 4.5GHz+ orajelen, 100+W-ot zabalva, mig a gpu a celhw miatt kozben tok jol elvan), am ez rohadtul irrelevans. mire akarsz kilyukadni? :)
2K-t elvinne ugyanazon az órajelen > aha, jaja, perszehogyne! megirtad ra a drivert es lemerted, vagy elohuztal valamit random a fenekedbol? :)
es nem dekodolasrol beszeltem. (re)encode-olasrol! :)
Ez az, amit majd az Intelen kérj számon. :)
Ugyanaz a hardverkomponens végzi, ha gyorsítva van.
Ugyanaz a hardverkomponens végzi > csak epp a ket muvelet szamitasi igenye teljesen mas. :)
tehat a seggedbol elohuzott imaginaris szamokkal magyaraztad a kepzelgesed. koszonjuk, Emese! :)
Ritka szar kifogás. Az megvan, hogy az mp3DirectCut ezt a feldolgozást™ megcsinálja 2% CPU-ból és harmadannyi memóriából? 🤡
Minden más CPU-n is bloat, mert bloat az implementációja.
Ezt megerősítem, az ffmpeg nem csak erre jó, hanem egy csomó minden másra, konvertálás, lejátszás, vágás, képeszközről rögzítés (képernyő, webkamera, stb.). Ezeket a fajta programok én svájci bicska szoftvereknek hívom, ilyen az imagemagick convert/display, sox, fzf, (n)vim, stb..
A másik, ami miatt jó használni, mert úgyis fent van minden *nix desktop rendszeren, valami másik szoftver, főleg videó/audiólejátszók beemelik függőségnek, és felteszik, így szinte mindig fent van, ha meg már fent van, akkor már használjuk valamire.
Alapvetően az említett aac-vágós problémára is ffmpeg-et használtam volna reflexből, de nem garantál frame-határon vágást.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ez szerintem nem jó, amit írtál. Ez az ss időbélyegzővel működik, és nem biztos, hogy frame-határon vág. Nekem olyan megoldás kéne, ami ezt garantálja. Az mp3slpt garantálja, de az csak mp3, ogg/oga fájlokkal tud dolgozni, az aac-t, opus-t nem ismeri, amiben a JuhTyúk tárol.
Igen, egyébként a terminálban szinte majdnem minden megoldható, de vannak kivételek, elég ritkán, az ilyen probléma nálam kb. évtizedenként előjön egyszer, de a gyakoribbak is csak szökőévente. Ez ilyen. A világ nem ideális. Ettől még a CLI/TUI megoldásokat preferálom, és a mindennapokban 99%-ban azon vagyok, lényegében a böngészőt kivéve. El sem hinnéd, hogy a sok GUI megoldás nélkül mennyivel soványabb egy rendszer, mind a procira, mind a memóriára, mind a csomagok számára, telepítési méretre, stb.. Általában a hibakeresést is megkönnyítik, ha valami nem működik, meg ezek a programok könnyen portolhatók is más rendszerekre.
Neked egyébként ez a CLI/TUI azért morbid, mert nem ismered a világát, meg Windowson ezek szarok, de *nix rendszereken nem ez a helyzet. Ott normálisabbak a shell (konfigurálhatóbb, kiegészítéssel is segít), terminálok jobbak, CLI/TUI programokból is több van. Az a baj, hogy úgy alkotsz véleményt, hogy CLI-ből max. DOS-t meg WinXP Parancssorát láttad, azok köszönőviszonyban nincsenek valóban egy normálisabb megoldáshoz képest.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Nem véletlenül írtam mellé az MP4Box-ot. Kipróbáltad?
Jó reggelt! 🤡
Pontosan ismerem a világát. A fenti kis kommented éppen azt bizonyítja, hogy nálad jobban ismerem.
Rendszeresen látok Linux parancssort, csak legtöbbször van előtte egy SSH, de ezt huszonötezerszer leírtam már neked. Az a helyzet, hogy nagyon szeretnéd rám sütni, hogy közöm nincs a TUI-hoz, a terminálos világhoz, mert így akkor nem kell elismerned, hogy vannak nem bloat GUI-s appok, amik sokszorta hatékonyabbak a terminálosaknál és méginkább hatékonyabbak a GUI-s bloat appoknál. Az mp3DirectCut éppen egy ilyen szoftver, de ilyen még a Total Commander, az IrfanView, az MPC-HC. Ideje lenne elfogadnod végre. Ja és ennek lófasz köze nincs a Windows XP, DOS stb. beépített parancssorához, aminél valóban sokszínűbb egy bash, zsh, akármi, de ez nem döntő ok a Windows XP ellen, vagy a Linux mellett, elvégre ezek a shellek Windows XP-re is elérhetőek.
Az MP4Box felett elsiklottam, arra ránézek.
Egyébként meg nincs igazad, hiába hajtogatod. Ezek a kedvenc programjaid, TC, IrfanView, MPC-HC/MPC-BE mind kiválthatók, elhagyhatók. Semmi annyira világmegváltás nincs bennük, mint gondolod. Nem rossz szoftverek, főleg a mai soydev/web/Electron felhozatalhoz mérve, de nem nélkülözhetetlenek, amit te ezekkel megcsinálsz, én azt szintén megcsinálom Vifm/nvim/fzf kombóval, meg az ezekhez drótozott pár soros scriptjeimmel, IrfanView-t simán kiváltja az Imagemagick, az MPC-t meg az mpv.
Az írásaidból nekem továbbra is az jön le, hogy a CLI/TUI világot nem ismered. Azt nem kétlem, hogy néha ülsz SSH előtt, de a rejtett trükkjeit, ami meggyorsítja ezen programok használatát és hatékonnyá teszi, azt nem ismered. Ezek a CLI/TUI megoldások sokkal gyorsabbak, egyszerűbbek a legtöbb esetben, átláthatóbb módon működnek. Tab-os, Ctrl-R-es kiegészítésnek, alias-oknak, pipe-olásnak, readline, bash/zsh beállításoknak, tmux-nak, stb. majd nézz utána, ezen a nyomvonalon indulj el. Természetesen ez nem az a műfaj, amit 5 perc alatt megtanulsz és megszoksz, idő kell hozzá, mindig használgatni, ismerkedni 1-1-gyel, mikor időd van, meg alkalom arra, hogy használjad.
Egyébként ez valóban nem az XP-n múlik, mert elvileg a FOSS és *nix-es eszközök simán portolhatók lennének rá, de nem dolgozik meg vele senki, mert a rendszer maga már egy agyonavult őskövület, semmilyen vonásában nem releváns már, ment a történelmi süllyesztőbe a CP/M, MS-DOS, OS/2, stb. mellé. Értelme sem lenne vele fejlesztőnek megdolgozni, hogy XP alá portolgasson, meg ősverziós Visual Studio-val fordítgasson, mert a szóban forgó szoftverek úgyis elérhetők releváns, ingyenes, modern rendszereken. Akinek ezekre van igénye, nem kell neki XP-re portolni, mert átmegy érte más rendszerekre, vagy máris azokat használja. Sok ilyen eszköz valóban máris elérhető XP-re, sok GNU coreutil, Bash, zsh, meg cygwin, és társai, de akkor sem fognak annyira koherensen működni, mert a rendszer, ami alattuk van, abba nem tudnak olyan mélyebb szinten integrálódni.
Egyébként ez az Mp3DirectCut esete továbbra is bosszant, azért blogoltam róla itt a topikban. Ha más nem két programmal kiváltható lenne, egy olyan lejátszóval, ami lejátszás közben írja, hogy épp melyik frame-nél van, meg egy low level CLI toolra, ami megadott, szám szerinti frame-eket töröl, ezt illene belevenniük az FFmpeg-be.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Szuboptimális megoldásokkal, kompromisszumokkal. Jahogy neked éppenséggel még kiváltanod sem sikerült. 🤡
Tudod, Raynes kolléga, ez úgy működik, hogy van a szélsőséges idealizmusod, a FOSS- és CLI-huszárkodásod, amiről 100 hozzászóláson keresztül bullshitelsz, aztán szembejön a valóság. :P
Nem gondolom, hogy világmegváltások lennének ezek az alkalmazások. Viszont kiállták az időpróbát, kiállják az erőforráspróbát, kiállják a kompatíbilitás-próbát (lásd wine-nal is tudod gond nélkül futtatni őket), és a funkcionalitás-próbát is.
Csak ha épp szembejön egy olyan funkció, amit a kombóid nem tudnak, akkor majd megint nézel egyet és kénytelen leszel szégyenszemre wine-nal elindítani valamelyik "világmegváltást". Aztán mondhatod megint, hogy nem volt igazam. 🤡
Lehet, hogy van a CLI/TUI világnak olyan szeglete, ahol te több kapcsolót, paramétert stb. tudsz fejből, de el tudok igazodni ebben a világban olyan jól, mint te és nem érzem magam elveszve, ha elém kerül egy Linux terminál, elvégre minden héten elém kerül jónéhány, SSH-n keresztül.
Kivéve az általad is felsorolt "világmegváltó" GUI-s appokat, mert azok jóval átláthatóbbak. Ettől függetlenül, igen, a KISS irányelveket nem felrúgdosó CLI/TUI megoldások jól integrálhatók egymással és képesek átláthatóan működni. Kivétel ez alól, amikor babzsákfejlesztőék megváltoztatgatják, deprekálgatják a parancssori kapcsolókat az újabb verziókban. Mert ugye a frissítésmániád se felejtsük ki a képletből. :P
Kettőnk között az a különbség, hogy te mindenre is CLI/TUI-t akarsz használni (legalább is szavakban, mert ezzel az mp3DirectCut-os felsüléssel eléggé önellentmondásba keveredtél), én meg arra használok CLI-t, amire az a hatékonyabb. Te elvből utasítod el a GUI-s appokat. Én nem utasítom el elvből a CLI-t, sőt ugyanúgy nélkülözhetetlennek tartom, mint akár a Total Commander-t. Te azt próbálod bemagyarázni, rámsütni, hogy én CLI-ellenes vagyok, de nem vagyok az. Aztán, amikor ezt nem sikerül rámsütni, akkor azt próbálod, hogy nem értek hozzá. Ez sem igaz. Két évtizede dolgozom aktívan CLI-vel. Van benne rutinom, ha annyi nincs is, mint egy hozzád hasonló (papíron) parancssorhuszárnak, de eligazodom benne annyira, amennyire számomra szükséges.
Ezzel szemben a valóság: Friss ffmpeg, Python és yt-dlp is van XP-re. Mert van, aki dolgozik rajta. Nem értem egyébként, hogy miért mondasz véleményt egy olyan világról, közösségről, amit kibaszottul nem ismersz. Nem szégyen persze, mert semmit nem akarsz csinálni XP-n, de akkor legalább hülyeségeket ne beszélj.
Pedig van értelme, méghozzá az, hogy nem kell frissíteni (és újravásárolni a gépet, amin XP van, mert frissebb rendszer már nem futna driverek híján vagy a bloat miatt), csak azért, mert babzsákfejlesztőék előre a semmibe rohannak. De az is lehet, hogy valaki ezt hobbiból csinálja. Mint ahogy valaki C64-re portol olyan játékokat, amikről álmában sem gondolta volna senki, hogy működne rajta. Szerencsére vannak még emberek, akik nem átkozott befektetőlogikával gondolkodnak és csinálnak azért projekteket, hogy modernnek tűnjenek, meg jól mutasson a GitHub-jukon.
Írtál nekik? Ha őket fele annyit cseszegetnéd, mint engem az XP-vel, már lehet, hogy beleraknák a frame-helyes vágást.
Közben néztem, az MP4Box nem tudja, amit akarnék. Viszont becsülendő, hogy ismersz ilyen programokat, ez tényleg azt jelenti, hogy használgatsz modern rendszert is. Nagyon helyes csak, nézegessél ilyeneket, menjen csak SSH, linuxos shell, majd fejlődsz idővel. Nem kell siettetni, ez olyan, mint egy utazás, egy hosszabb folyamat, nem 5 perc után van eredménye, ahogy írtam.
Igen, a CLI/TUI mindenre elsőnek szélsőségesnek tűnhet, szokni kell, de igazából marha jó. Tudsz köré saját scripteket írni, fzf gyorskeresést, gyorsbillentyűket bedrótozni, így egy jóval gyorsabb workflow gyúrható belőlük, plusz a CLI/TUI programoknak van egyfajta distraction-free jellege, hogy mindenféle GUI elemmel, vizuális zajjal nem vonják el a figyelmed a nyers adatokról, azokat low level szinten te tudod úgy kezelni, átlátni, átcsoportosítani, hogy minden döntés-irányítás a te kezedben van, te uralod a saját rendszered, te mondod meg, hogy mi hogy fusson. Engem kicsit a DOS-os időkre emlékeztet, amit már akkor is nagyon szerettem, visszaadta a PC-k használatának az élvezetét, ami a modern GUI-kkal kiveszett teljesen. Egy nagyon jó dolog, csak te vagy hozzá normi, mert ilyen szempontból áttereltek téged is a nagy mulitk (MS, IBM, stb.) GUI-ra, és elhitették veled az idők folyamán, hogy GUI az elengedhetetlen, megáll az élet nélküle, a CLI/TUI-t nem tudod kezelni, mert túl együgyű vagy hozzá, csak 1 gombokra vagy 1 nagy ikonra tudsz kattintgatni. Nagy tévedés, mert tudnád, csak át kell szokni, ez csak mentalitás, megszokás kérdése.
Az ffmpeg-nek mindenképp tolok be feature request-et a git-jükre, bár ez nem garantálja, hogy megcsinálják. Ebben teljesen igazad van, hogy addig nem is fogja tudni, amíg valaki ezt nem kéri, és egy fejlesztő nem implementálja. Egyébként így is szép teljesítmény, hogy ilyen ritkán van szükség Mp3DirectCut-ra, nekem is ennyi évbe tellett, mire kellett valamire. Tényleg nem is értem, mert az aac/m4a konténerre, és az AAC alapkódekre (AAC-LC) lejárt már a szabadalom 2020 környékén, mint az mp2/mp3-ra, így már szabadalmi, licenckérdés sem lenne akadálya az implementációnak. Külön érdekes, hogy mp3, ogg Vorbis kódekre ezt már tudja több megoldás is, de AAC, Opus ennyire nem támogatott még ilyen téren, ez egy lemaradás, amit be kéne hozni. Implementálni is nagyon könnyű, mert az eredeti kódban csak arra kell figyelni, hogy ha x-y frame között van, azokat ne másolja át az új fáljba, tehát nem igényel túl nagy kódsort, egy 2 soros if-then-else szerkezetet kell beleszerkeszteni a kódba, vagy egy case esetkört bővíteni, meg hozzá CLI opciókat kivezetni egy másik 2-3 programsor, nem kell hozzá Linus Torvaldsnak, John Carmack-nak, vagy programozózseninek lenni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Sajnálom. Ezek szerint mégis csak szükség van a "világmegváltó" GUI-s appokra. :)
A modernitás egy illúzió, aminek te is bedőltél. Használok működő rendszereket. Ennyi és nem több. Amúgy értékelem az elismerésed, de jobban örülnék annak, ha végre befejeznéd az értelmetlen közhelyeid erőltetését azzal kapcsolatban, hogy a tapasztalataim, használati eseteim stb. kizárólag XP-re korlátozódnak és csőlátással tekintek minden másra. Ezt nagyon sokszor leírtam és bebizonyítottam neked, hogy nem így van, mégis erőlködsz. Miközben valójában te vagy csőlátású a CLI/TUI felé.
Nem tekintem fejlődésnek egy XP-től eltérő rendszer használatát. Te tekinted illuzionálils fejlődésnek, mert van egy "újabb=jobb" kényszerképzeted.
Mégis sietteted már évek óta. 🤡 Nem vagyok kezdő Linuxos. Ha elém raknának egy Linuxot, valószínűleg ugyanúgy el tudnék végezni rajta mindent, csak kevésbé hatékonyan. A macOS-re és a FreeBSD-re is igaz ugyanez. Nem azért vagyok XP-n, mert félek más rendszerektől, vagy mert nem érte(né)k hozzájuk. Azért vagyok XP-n, mert más rendszerek ismerete mellett úgy döntöttem, hogy XP-n maradok, mert ezen a leghatékonyabbak azok a dolgok, amikkel foglalkozom. Felfogod végre?
Kettőnk közül a multik csak neked mosták át az agyad azzal, hogy mindenből frisset kell használnod. Nem hitette el velem senki, hogy a GUI elengedhetetlen. Leírtam az előző kommentemben is: "Én nem utasítom el elvből a CLI-t, sőt ugyanúgy nélkülözhetetlennek tartom, mint akár a Total Commander-t. Te azt próbálod bemagyarázni, rámsütni, hogy én CLI-ellenes vagyok, de nem vagyok az. Aztán, amikor ezt nem sikerül rámsütni, akkor azt próbálod, hogy nem értek hozzá."
Nem kéne write-only fórumozni, Raynes.
Majd veregesd vállon magad. 🤡 Én addig előszeretettel fogom preferálni a századannyi CPU-ból és harmadannyi memóriából audio-t vágó mp3DirectCut-ot, amellett, hogy az ffmpeg és az MP4Box ugyanúgy fent van és bármikor nyitok egy billentyűkombóval egy parancssort és használom.
Erre már jó ideje van kvázi-szabványos megoldás, melyet minden normális kommersz lejátszó tud. "Replay gain" néven érdemes rákeresni.
:)