Jedną z najważniejszych i podstawowych części tworzenia pliku simfile dla dowolnego stylu gry jest zapewnienie prawidłowej synchronizacji charta. Ucząc się, jak prawidłowo zsynchronizować plik, często można usłyszeć o znaczeniu zastosowania "9ms bias" do danych synchronizacji pliku. Ten element tworzenia treści istnieje w społeczności od wielu lat, ale jego pochodzenie i cel są często tracone lub błędnie komunikowane z powodu braku łatwo dostępnej dokumentacji na ten temat.
Uwaga: 9ms bias było przez lata różnie określane jako "9ms bias", "9ms offset", "offset ITG" i wiele innych terminów. Ze względu na wewnętrzną spójność, ten artykuł będzie odnosił się do niego jako "9ms bias" lub "bias".
Czym jest 9ms bias?
Mówiąc prościej, 9ms bias to dodanie 9 milisekund do wartości #OFFSET pliku simfile, której Stepmania używa do określenia, kiedy dane charta pliku zaczynają się w stosunku do danych audio pliku. Powoduje to, że chart, a w konsekwencji dane taktowania kroków, rozpoczynają się 9 milisekund wcześniej. W inny sposób powoduje to, że dźwięk utworu zaczyna być odtwarzany 9 milisekund później.
Jako krótki przykład, powiedzmy, że mamy utwór o znanym stałym BPM, który został przycięty i zsynchronizowany w taki sposób, że pierwszy takt muzyki pojawia się dokładnie na początku pliku audio, w znaczniku czasu 0,000 sekundy. W tym przypadku, zakładając, że nasz BPM jest prawidłowy (w tym przykładzie jest), synchronizacja pliku z "9ms Bias" wymaga ustawienia wartości #OFFSET na 0,009, a nie 0,000, jak można by się spodziewać.
Jak można sobie wyobrazić, może wydawać się mylące, a może nawet nielogiczne, że "poprawna" synchronizacja pliku simfile wymaga celowego ustawienia synchronizacji pliku na 9 milisekund. Dlaczego mielibyśmy to robić? Aby to zrozumieć, ważne jest, aby zrozumieć historię i pochodzenie tej części tworzenia plików simfile.
Pochodzenie 9ms biasu
Po wprowadzeniu wersji 21 ITG 2, która umożliwiła łatwiejsze dodawanie i odtwarzanie niestandardowych plików simfile stworzonych przez użytkowników, wielu graczy zauważyło, że ich niestandardowe pliki często nie były zsynchronizowane, a kroki były niezwykle opóźnione, nawet jeśli dźwięk pliku został precyzyjnie przycięty i zsynchronizowany co do milisekundy przy użyciu DAWów. Jeden z twórców treści i graczy, znany jako mute, zbadał kodowanie i dane ITG 2 i odkrył, że programiści ITG dodali modyfikację do silnika StepMania 3.95, która odejmowała 12 milisekund od wszystkich wartości #OFFSET pliku simfile, sprawiając, że wszystkie pliki audio rozpoczynały odtwarzanie 12 milisekund wcześniej niż wynikało to z ich indywidualnych wartości #OFFSET. W konsekwencji wszystkie dane kroku i taktowania były opóźnione o 12 milisekund. Powodem podanym w komentarzach do kodowania ITG 2 było to, że miało to na celu "uwzględnienie opóźnionych strzałek ITG" - biorąc pod uwagę, że zmiana ta "uwzględniała" opóźnione kroki, czyniąc je jeszcze późniejszymi, powszechnie zakłada się, że był to błąd programistyczny.
Po tym odkryciu mute zaproponował, że aby przeciwdziałać 12-milisekundowemu opóźnieniu, najprostszym sposobem działania byłoby celowe ustawienie wartości #OFFSET w plikach tworzonych przez użytkownika o 12 milisekund wyższej niż "powinna" być. W praktyce spowodowałoby to, że 12-milisekundowe opóźnienie (nieodłącznie związane z programem zręcznościowym ITG2 jako "globalne przesunięcie") i 12-milisekundowe dodanie w samym simfile zniosłyby się nawzajem, co spowodowałoby, że "właściwy" czas kroku byłby dokładnie dopasowany do rytmu (rytmów) utworu.
Wkrótce proces ten został jeszcze bardziej udoskonalony. Inny gracz i twórca, winDEU, poszedł o krok dalej i obliczył czas, w jakim fale dźwiękowe przemieszczają się od głośników automatu do uszu gracza, zakładając rozsądne średnie wartości zarówno dla odległości automatu, jak i wzrostu gracza, i stwierdził, że czas ten wynosi średnio 3 milisekundy. (Przypomnijmy - w tym czasie publiczne automaty arcade były standardem dla ITG, więc te "założenia" były w dużej mierze kompletną rzeczywistością dla większości graczy). W praktyce oznaczało to, że gracz zazwyczaj słyszał dany dźwięk 3 milisekundy po tym, jak dane kroku pliku simfile "oczekiwały", że go usłyszy. Aby zaradzić tej rozbieżności, winDEU zaproponował, aby zamiast dodawać 12 milisekund do wartości #OFFSET pliku simfile, twórcy treści powinni zamiast tego dodać 9 milisekund, co zapewniłoby, że dźwięk dotarłby do uszu gracza dokładnie w momencie, w którym miał on nadepnąć na daną strzałkę (zakładając prawidłową synchronizację charta).
Z czasem praktyka ta ostatecznie stała się standardem tworzenia dobrze zsynchronizowanych niestandardowych plików simfile do odtwarzania na automatach ITG2 z obsługą wersji 21, w dużej mierze przyjętym przez większość, jeśli nie wszystkich, twórców treści w tamtym czasie. Innymi słowy, przez znaczny okres czasu w historii "ITG", jaką znamy dzisiaj, cała niestandardowa zawartość była celowo tworzona z 9-milisekundową rozbieżnością synchronizacji między dźwiękiem a krokami, ponieważ był to jedyny sposób na zapewnienie, że zostaną one "poprawnie" zsynchronizowane na dostępnym wówczas sprzęcie arcade.
Jak 9ms bias stał się standardem
Z czasem jak niestandardowe kompilacje StepMania zarówno dla automatów arcade, jak i (ostatecznie) domowych konfiguracji stały się zarówno bardziej powszechne, jak i bardziej zróżnicowane pod względem sprzętu, gracze i operatorzy zaczęli odkrywać i sprawować większą kontrolę nad kilkoma opcjami i parametrami w silniku StepMania, które wcześniej były niedostępne na standardowych automatach arcade ITG2. Najbardziej istotną opcją dla tej dyskusji była możliwość zmiany wartości globalnego offsetu maszyny lub konfiguracji, która, jak wspomniano wcześniej, była pierwotnie ustawiona nieprawidłowo w kodowaniu ITG2. Większość graczy i operatorów maszyn stwierdziła, że najbardziej praktyczną metodą ustawienia dokładnej wartości Global Offset było porównanie z plikiem, o którym wiadomo było, że jest "poprawnie" zsynchronizowany i ustawienie wartości Global Offset, zwykle wykonywane za pomocą funkcji Autosync Machine, w taki sposób, aby kroki wspomnianego pliku były odpowiednio dopasowane do dźwięku pliku.
Niezbędnym zastrzeżeniem do tego procesu było to, że przez kilka lat wszystkie niestandardowe pliki simfile były celowo tworzone z wartościami #OFFSET, które były celowo "nieprawidłowe" o 9 milisekund, aby uwzględnić niedociągnięcia, które były nieodłącznie związane z grą od jej początków. W związku z tym użycie funkcji Autosync Machine do dostosowania globalnego offsetu w oparciu o te pliki symulacji spowodowało wewnętrzne "odchylenie" w globalnym offsecie maszyny, które sprawiło, że pliki symulacji, które były "nieprawidłowe" o 9 milisekund, w rzeczywistości brzmiały i grały tak, jakby były idealnie zsynchronizowane.
Choć może się to wydawać niewłaściwe, z praktycznego punktu widzenia był to najrozsądniejszy sposób działania w tamtym czasie. Chociaż domowe automaty i inne niestandardowe systemy powoli stawały się coraz bardziej powszechne, w większości przypadków zdecydowana większość graczy nadal korzystała z systemów arcade, zarówno dedykowanych automatów ITG2, jak i automatów "ulepszonych", aby grać w niestandardową zawartość. W związku z tym większość układów nadal musiała być zaprojektowana w sposób uwzględniający dziwactwa i niedociągnięcia standardowych systemów ITG2, a (w tamtym czasie) mniejszość graczy korzystająca z systemów domowych uznała za łatwiejsze i bardziej praktyczne przyjęcie tych samych standardów dla własnych systemów, ponieważ większość dystrybuowanej i odtwarzanej zawartości została stworzona z myślą o tych standardach. Dla każdego pliku simfile, który został zsynchronizowany z dokładnością do znaczników czasu bitów audio (powszechnie określanych jako "synchronizacja z zerowym offsetem"), istniały dziesiątki istniejących plików, które zakładały, że są odtwarzane na maszynie z globalnym offsetem, który uwzględniał ich wewnętrzną, celową niedokładność.
W związku z tym, nawet gdy systemy oparte na arcade powoli odchodziły na dalszy plan, a systemy domowe (kupowane przez użytkowników automaty arcade lub własne maszyny do StepManii) stały się bardziej rozpowszechnione, ze względu na samą masę istniejącej zawartości, która była zgodna z tymi (teraz teoretycznie niepotrzebnymi) standardami, przeciętnemu użytkownikowi końcowemu lub twórcy treści było po prostu łatwiej kontynuować przestrzeganie standardu 9ms, nawet gdy przyczyny jego istnienia nie były mu do końca znane.
9ms bias i społeczność StepManii Post-ITG
Na współczesnej scenie "ITG" 9ms Bias jest nadal wykorzystywany jako standard w tworzeniu plików symulacji, mimo że jest niepotrzebną modyfikacją, która w dużej mierze istnieje tylko jako dziwactwo "starszych" systemów. Biorąc pod uwagę obecny stan gry, można się zastanawiać, dlaczego bias nadal istnieje jako standard i dlaczego społeczność graczy i twórców treści jako całość nie odchodzi od niego.
Odpowiedzią na to pytanie jak wygoda gracza. Chociaż jest to obiektywnie "niepoprawne", nadal jest to w praktyce wygodne dla dużej części bazy graczy "ITG", ponieważ wielu graczy, niezależnie od ich konfiguracji, nadal gra w treści, które zostały stworzone w erze "starszej" lub zostały stworzone zgodnie ze standardami wymaganymi przez tę erę. W rezultacie maszyny i konfiguracje, które mogą odtwarzać dowolną z tych treści, mają wartości globalnego przesunięcia, które je uwzględniają, a każda nowo utworzona zawartość, która jest dodawana do tych maszyn, rzekomo musi być również zaprojektowana tak, aby pasowała do tego dostosowania, nawet jeśli systemy, dla których została pierwotnie stworzona, zostały w dużej mierze wycofane z użytku.
Podczas gdy od czasu do czasu toczyły się dyskusje na temat odejścia całej społeczności od stosowania 9ms biasu (co byłoby dużym ułatwieniem dla twórców treści), wykonanie takiego zadania z pewnością byłoby zniechęcające i obarczone potencjalnymi problemami i błędami, ponieważ przytłaczająca masa niestandardowych treści dystrybuowanych, udostępnianych i ponownie udostępnianych przez ponad dekadę wymagałaby ponownej synchronizacji wszystkich swoich plików aby usunąć 9ms bias ze wszystkich plików (zakładając, że nie ma wcześniejszych błędów synchronizacji), a na graczach i operatorach maszyn spoczywałby obowiązek zarówno pozyskania tej nowo zsynchronizowanej zawartości, jak i zmiany wartości globalnego offsetu ich gry, zakładając, że jest to dla nich możliwe i praktyczne. Bardziej wygodną i praktyczną metodą, którą wielu twórców treści już zaczęło stosować, jest dostarczanie wielu wersji ich treści, aby pomieścić oba typy konfiguracji, Null i 9ms. Chociaż niekoniecznie rozwiązuje to pierwotną przyczynę, jest to znacznie bardziej praktyczna i wygodna metoda pozwalająca członkom społeczności, którzy chcą odejść od długo nieistotnej mechaniki, aby to zrobić, jednocześnie pozwalając graczom, którzy grają i cieszą się starszą zawartością (lub w inny sposób nie są w stanie zmodyfikować globalnego offsetu swojej konfiguracji), aby nadal cieszyć się owocami pracy twórcy treści.
Ostatecznie jest to problem trudny do rozwiązania. Być może najrozsądniejszym i najbardziej logicznym sposobem działania jest po prostu upewnienie się, że społeczność jako całość rozumie, czym jest 9ms bias, dlaczego istnieje i, prawdopodobnie, dlaczego powinien nadal istnieć, dopóki nie zostanie ustalone bardziej eleganckie rozwiązanie.
Źródło
https://itgwiki.dominick.cc/en/packs-and-simfiles/the-9ms-bias
Artykuł dostępny pod licencją Creative Commons Attribution-NonCommercial-ShareAlike