チップ音の再利用を禁止する意味はあるのかな。(でも本体がオープンソースである以上、すぐ破られちゃいますね・・・)
from そういえば、BandJAM にも GDS 形式っていうバイナリ形式がありましたねー。
サンプル曲の Goonie Kids とか。
即行で廃止されて GDA に代わりましたけど。
songs.db もそうですが、バイナリデータは百害あって一利無しですよ。
処理もコンパイル前より重たくなりますし。
偽装対策なら電子署名でも入れとけばいいなかーと思います、個人的には。
偽装対策なら電子署名でも入れとけばいいなかーと思います、個人的には。
DTXデータの改竄検出は確かに電子署名で問題なく実現できますが、むしろ本当に偽装対策したいのはscore.iniの方であって、こっちは電子署名じゃダメなんですよねぇ。とほほ・・・。
from むしろ本当に偽装対策したいのはscore.iniの方であって、こっちは電子署名じゃダメなんですよねぇ。とほほ・・・。
オープンソース化する前の DTXMania の秘密鍵は、圧縮画像データと乱数を用いている上に DTXMania のモジュール全体にダミーをちりばめていましたから、たとえ逆解析されても、モジュールを時系列に解釈できないと正解を見つけられないのでそう簡単には見破られないという自信はありました。（幸い？Reflector も有償化されましたし。）
が、オープンソース化するにあたって、わざわざそれらの秘密鍵の部分をごっそり除去しましたからねえ。
通信部分のみ非オープンソースな別モジュールにすることも考えたことがありますが、モジュールが小さくなるからネイティブであっても比較的逆解析が容易になってしまうんですよねー。
コンパイルというか、1つのファイルにまとめるという需要はあるようです。
それならば、安直にzipでまとめたものを扱うということでいいような気がします。拡張子は変えた方がいいと思いますが。
それと、score.iniファイルの保存をどうするかが、悩ましいですね。都度zip内に入れ込むのも遅そう。
from Song Enumeration にすごく時間がかかりそうですねー……
一度enumerateしてしまえば、あとはzipのタイムスタンプをチェックしてスキップできるので、むしろenumerateが早くなる可能性すらあります(複数の曲データが1つのzipに入っている場合)。
でも、１回目のenumerationは、遅いでしょうね・・・
Fork
使用ファイルのコンパイル化(dtxファイル/音源ファイルを１つ程度のファイルに纏める→不正対策･･･は意味あるのか)
(フォーラム ユーザフォーラム [#62465] からの引用。)