作为一个Jubeat玩家,并且还想过那些比较难的曲子,怎么样也会听说过Jubeat Analyzer吧。这个工具可以把街机上那些谱面在电脑上重现出来,这样就可以先看清楚它是怎么回事,然后再去玩,增加过关的概率。
这软件读取的谱面格式是TXT,音乐是MP3。看它的readme,里面有提到谱面的TXT的格式。里面有写曲子的速度(每分钟多少拍),从什么地方开始是第一拍,之类的。
它自带两个曲子,我当时研究了一下那个twilight goose,发现里面写的曲子第一拍开始的时间是1747毫秒。但是实际上我把MP3丢到Audacity里面打开,仔细观察,第一拍在1.5秒左右就开始了。 继续阅读Jubeat Analyzer(mciSendString)对待MP3奇怪的行为 →
最近做了个Jubeat Analyzer的谱面转成Yubiosi谱面的工具。在制作工具的过程中,遇到了一个问题,就是源谱面文件中字符串的编码问题。
Jubeat Analyzer是日本人造的软件,然后它保存的谱面又没有用Unicode,所以在中文操作系统上看就会乱码。对于编码转换问题,其实C++是可以直接支持的。对于一个支持输出宽字符的文件流,把区域设置到japanese就可以了,像这样:
std::locale jpLoc("japanese");
std::wfstream fs("c:\\nanika.txt", std::ios::in);
fs.imbue(jpLoc);
如果问题这么简单就解决的话就好了……
问题是,源文件中不仅仅包含ShiftJIS编码的部分,而且还包含GBK编码的部分。比如某些地方的注释,某些 m="音乐文件名" 的地方。因为如果音乐文件名用的是ShiftJIS,那么在中文系统下就没办法正常读取音乐了。
这种情况下,来一个imbue不能解决问题。因为它读到ShiftJIS不能表示的字符的时候,这个流就给你eof掉了……
既然这样,那我就一行一行读,不同情况不同处理。自己转成Unicode。好吧,怎么转
用MultiByteToWideChar固然简单,但是我想要用C++标准库去做而不是调用系统API。因为你看,wfstream都可以读取ShiftJIS文件到wstring,那么说明内部一定有什么代码实现编码转换的。我想办法调用这编码就行了。 继续阅读在C++中进行字符串编码转换 →
Hello,
Recently I write a client for icecast. It can broadcast the audio from both stereo mixer and microphone to an icecast server.
It’s mainly written in C++, and the GUI in C#, distributed in 3-clause BSD licence.
It uses boost and portaudio library.
Any comment is welcomed.
Hello,
Recently I write a client for icecast. It can broadcast the audio from both stereo mixer and microphone to an icecast server.
It’s mainly written in C++, and the GUI in C#, distributed in 3-clause BSD licence.
It uses boost and portaudio library.
Any comment is welcomed.
测试昨天的代码的时候,又遇到了问题。把整个处理流程又加长之后,其中有一个进程的输入和输出都被重定向了。因为昨天测试的时候都是中途强行停止,现在想要正常停止,自然就是把连接自己和子进程StdInput的管道HANDLE关闭,结束送数据。但是我关掉管道输入端的HANDLE以后,子进程却还在傻傻等待数据,也不退出。 继续阅读搞死人的管道HANDLE,搞死人的继承 →
因为Boost.Iostreams提供了封装Windows的Handle的支持,利用这个可以简化匿名管道的操作。我想要达到的目标,先实现这样一个简单的命令行:
ffmpeg -i c:\1.mp3 -acodec pcm_s16le -ac 2 -ar 44100 -f s16le - | oggenc2 -o c:\1.ogg -q 1 -B 16 -C 2 -R 44100 -
功能很简单,就是把一个mp3文件转换成ogg文件而已。然而要达到这个目的,耗了不少精力…… 继续阅读使用Windows的匿名管道和Boost.Iostreams →
因为Boost.Iostreams提供了封装Windows的Handle的支持,利用这个可以简化匿名管道的操作。我想要达到的目标,先实现这样一个简单的命令行:
ffmpeg -i c:\1.mp3 -acodec pcm_s16le -ac 2 -ar 44100 -f s16le - | oggenc2 -o c:\1.ogg -q 1 -B 16 -C 2 -R 44100 -
功能很简单,就是把一个mp3文件转换成ogg文件而已。然而要达到这个目的,耗了不少精力…… 继续阅读使用Windows的匿名管道和Boost.Iostreams →
之前不是做了个东方游戏的音乐ogg vorbis化的工具吗,现在xiph又出了一个新的编码叫做opus,于是想试试。不过它原生支持的是48kHz采样率,没有44.1kHz。看官方的说明,是推荐在需要的时候resample而不是更改代码让它支持44.1kHz。
本人对resample算法又没有研究,自然第一个想到的是去找现成的代码。网上搜索了一下,gpl啊lgpl协议下的代码倒是不少,这些协议都对私有软件不太友好。以后万一要做私有软件的话这些库就不能用了。
于是想着找个协议宽松一点的吧,网上看到有人推荐speex里面的resample。找是找来了不过一开始怎么样就是编译不过去。然后看到有人说opus_tools那一包代码里面也包含了这个resample,所以去参考了一下那边是怎么调用的。 继续阅读speex里提供的resample代码 →
C++里面调用COM感觉实在有点蛋疼,那些个什么Object搞得人略头大,总之我自己是还没熟悉它那个编写方式。
然后就去上网找Helper库,找到个DispHelper,感觉很神奇……它提供的那些个语法,很像VBScript那一类里面的用法诶。 继续阅读发现一个神奇的辅助调用COM的函数库 →
网上关于伪春菜的资料真的好难找啊><
用户群不够大的样子……然后好多还是日语的
SAORI可以认为是SHIORI的插件,SHIORI是控制人格执行的程序,通常这个程序只提供了一个脚本语言解释器(比如YAYA),更加具体的功能由这些脚本来完成。这种脚本、解释器分离的模型为更改程序提供了方便。如果每次更改都要重新编译整个SHIORI,这就太“GEEK体验”了。我们要的是“用户体验”XD 继续阅读伪春菜SAORI的编写 →
现在域名是 blog.sorayuki.net ~