Type 1/2 midi fájlok esetében a lehetséges track-ek (sávok) száma 65536 (16-bites érték tárolja).
DE ez nem jelenti, hogy a nem használt track-eknek lenne valamiféle foglalt helye. Nincs értelme azt mondani hogy "ez a midi fájl csak 2 track-et használ a 65536-ból" mintha akkor maradna 65534 üres track.
Annyit lehet biztosan mondani, hogy Type 0 midi fájlok esetében csak 1 track van, ehhez nem kell tovább szkennelni a fájlt.
Midi fájlok esetében a tartalom teljes szkennelése nélkül nem lehet megmondani, hogy egy track tartalmaz-e "zenei tartalmat".
Egyébként meg adódik a kérdés, hogy mi az a "zenei tartalom"? Csak a Note On/Off event-ek ?
Pl. ha egy Type 1 midi fájl esetében egy track csak Controller event-eket (hangerő, balansz stb.) tartalmaz, de ugyanarra a csatornára vonatkozóan, mint egy másik track ahol viszont a Note On/Off event-ek vannak, akkor a track tartalma minek számít?
Szerintem ez nem lett átgondolva. Maga a kérdés olyan homályos fogalmakkal dolgozik, ami alapján nem nagyon lehet egyértelmű válaszokat adni.
Igen, a 0 és 1 SMF formátumra én is gondoltam, de pont azért kérdezem mert nem tudom, hogy mondjuk olyan trackek amik nincsenek használva a 16-ból vagy 32-ből, hogyan vannak vajon nyilvántartva, merthogy voltak régen olyan szekvencerek is, amik 8 sávosak voltak, pl, Roland MC50. Illetve van-e olyan adat amiből egyértelműen kiszűrhető, hogy 1 sáv van használva. (?)
A kottamegjelenítés, meg hogy a Cubase stb. programok szétszedik több sávra, az más, de általában egy szóló zongora darab 1 sávra szokott 1 midi csatornát használva készülni.
ez így nem elég egyértelmű, tekintve, hogy a type 0 formátumban csak egy track van (amit a szekvencer program "szétszed" csatornánként, és a képernyőn már úgy jelenik meg), szóval minden az első sávon van - persze lehet azt mondani, hogy csak az 1 db csatornát (1-16) használó MIDI-k érdekelnek ebből a típusból
a másik oldalról (type 1 formátumnál, ahol sávok is vannak definiálva) egy zongora kotta általában két sávon (és esetleg 2 külön csatornán, de persze ugyanazon is lehet) van kezelve, külön a bal/jobb kéznek - itt meg mindkét 2 sáv kellene - vélhetően ez is megfogható a közös csatornával (ha épp ugyanarra a csatornára megy a 2 sáv)
szóval már a szűrés előtt is több lehetőség van - persze nem mondom, hogy nem megoldható, majd Zoltán :)
Totalcommanderben már vizsgálódtunk Kollégával a sysexet tartalmazó fájlok felől régebben...
Most arra keresnék ötletet, hogy milyen adat alapján lehetne azt esetleg leszűrni több száz midi közzül, ahol mindössze 1 tracken van felvett zenei tartalom (pl. szóló zongora darabok esetén)?
Úgy tűnik, hogy PHP az oldalon csak a szöveges meta event-ek jelennek meg, pl. tempo change, time/key signature nem:
Ha egyéb meta event-ekre is kíváncsi vagy használhatod a Midiplayer beépített Event Viewer/Debugger funkcióját. Ha a Filters menüben az "All Non-Channel Events" -t jelölöd ki akkor csak a meta és SysEx event-ek jelennek meg:
Nem, csak épp Pascal kódból másoltam, ott ez a hexa számok szintaxisa.
Meta event-ek esetében a státusz bájt mindig 0xFF és a második bájt adja meg a meta event típusát. Az alábbi listákban a hexa számok erre a második "meta event típus" bájtra utalnak.
Nem szőrszálhasogatásból, hanem csak hogy egyértelmű legyen a Text és Lyrics event-ek is meta event-ek. Szóval amelyik szinti képes Lyrics/Text információk megjelenítésére az valamennyire képes meta event-eket kezelni. A leggyakoribb "egyéb" meta event a jelenleg az exportnál használt Track/Sequence name meta event. Ha a szinyó ezt már nem képes sehogy sem megjeleníteni, akkor kicsi az esély, hogy egyéb meta event-eket tudna. Egyébként ezek az általam ismert meta event-ek:
metaSeqno = $00;
metaText = $01;
metaCopyright = $02;
metaTrackName = $03;
metaInstrumentName = $04;
metaLyric = $05;
metaMarker = $06;
metaCuePoint = $07;
metaProgramName = $08;
metaDeviceName = $09;
metaMiscText2 = $0a;
metaMiscText3 = $0b;
metaMiscText4 = $0c;
metaMiscText5 = $0d;
metaMiscText6 = $0e;
metaMiscText7 = $0f;
metaChannelPref = $20;
metaMIDIPort = $21;
metaTrackEnd = $2f;
metaTempoChange = $51;
metaSMPTE = $54;
metaTimeSig = $58;
metaKeySig = $59;
metaSequencer = $7f;
Közülük pedig ezek úgymond variable length/ szabad szöveges meta event-ek:
Egy ismerősömnél próbálgattuk a progidat és azt kérdeznénk, hogy mivel nem minden szinti képes meta információkat megjeleníteni a midi fájlokból és szerinte a lyricsben meg nem lehetne másik lehetőségként ezt a fájlútvonalat tárolni a "per" jelek miatt, mert az soremelést okoz ott, hogy ilyen lehetőségek volnának adottak még? (Persze ez csak elméleti kérdés, mert annyira a hangszeren nem kell ezt látni, hisz úgy is pc-n dolgozik a fájlokkal az ember válogatás szinten...)
A lyrics ablak betűmérete automatikusan változik az ablak méretétől függően. Amikor a betűtípus választót megnyitod akkor a dilaógusablak csak megmutatja az aktuális betűméretet. Próbáld meg átméretezni az ablakot, vagy maximalizáld és ezután nyisd meg újra a betűtípus választót. Látni fogod, hogy a méret megváltozott.
(szűrésre én jól tudom pl. a telóm media lejatszójában használni, hogy csak pl. az igazán tetsző ***** zenéket akarom hallani, meg ilyesmi, kb erre találhatták ki)
Bizonyára, de mivel én magam soha nem használtam ezt a pontozósdit semmilyen programban (és soha nem is értettem meg teljesen mi értelme van) elég nehéz lesz rávenni magamat az implementálására :) . Szóval nem akarlak hitegetni, a közeljövőben nem sok esélyt látok rá...
Hát ez extra number one! Nem is reméltem hogy... Már nézegettem pythonban épp hogy mit kéne összetákolnom mindehhez előzetes hozzáértés nélkül. Nem igen jött volna ilyen össze! :)
Jó ha a célkönyvtár üres, mivel a program soha nem ír felül meglévő fájlt az export során. Ha meglévő fájllal találkozik akkor az újat sorszámozza. Tehát pl. a második index.mid -> index (2).mid lesz. Így biztosítva van, hogy export során a különböző forrás könyvtárakból származó azonos nevű fájlok nem írják felül egymást.
Nem gondolom, hogy a midiplayer a legjobb eszköz ilyen feladatokhoz, úgyhogy még nem is döntöttem el, hogy szeretném-e látni ezt a funkciót a végleges verzióban. De mivel a keretek adottak a programban a feladathoz, a midiplayer-t használtam "template" -ként.
A rekurzív könyvtár feldolgozás már eleve adott volt, szóval annyi a dolgod, hogy rádobod a legfelsőbb szintű könyvtárt amiben a fájljaid vannak a Playlist felületre.
Ezután jelöld ki az exportálandó fájlokat Ctrl vagy Shift +bal egér click segítségével. Ha mindet ki akarod jelölni akkor jelöld ki az elsőt, majd görgesd le a végéig a playlist-et, majd shift+bal egér click az utolsó fájlon. Azért raktam bele a kijelölős dolgot, hogy ha akarsz akkor szegmensenként is tudj exportálni több különböző könyvtárba, nem kell feltétlenül mindent fájlt ömlesztve ugyanabba a könyvtárba rakni.
Ezután jobb egér click a playlist ablakán és "Export Selected Files to Folder" kiválaszt. Kapsz egy könyvtár választó ablakot ahol új könyvtárat is létre tudsz hozni (főleg szegmensenkénti exportnál lehet hasznos).
A program az export során beszúr egy új meta TrackName event-et az 1. track-be az eredeti útvonallal és fájlnévvel "Original: xxxx' formában. Fontos, hogy a player sok formátumot ismer (mid, xmi, mus, mds, rmi, kar) de csak .mid -et tud menteni, szóval mid -től eltérő formátumok esetében az export egyben konverziót is jelent (ugyanazt a memória képet menti amivel a player dolgozik lejátszás közben). Szintén fontos lehet, hogy ez a 32-bites verzió, amely a Win9x kompatibilitás miatt nem támogatja a Unicode -ot.
Tehát csak olyan ékezetes fájlnevek működnek, amelyet a Windows aktuális codepage-e (system locale) támogat. Tehát pl. magyar Windowson, (vagy olyan angol Windowson ahol a system loacale Hungarian-ra van állítva) a magyar ékezetes karaktereket. Egyébként a program megpróbálja a 8.3 formátumot használni, ez FAT32 esetében mindig adott de pl NTFS-en ki lehet kapcsolni. Bővebb info:
http://gnmidi.com - ennek voltak az ingyenes utiljai (midcopyr pld., amivel a copyright ba lehetett írni) csak eltüntette őket - esetleg gyanús kínai oldalakon megtalálhatók?
