id3libでID3からファイル名を持ってくる

id3lib
id3lib-3.8.3binaries.zip
id3lib-3.8.3.tar.gz
を落としてくる。

id3lib-3.8.3binaries.zipからは、Release以下のdllとlibを取り出す。
id3lib-3.8.3.tar.gzからinclude以下を取り出す。
pathを通しておく。

リネーム用プログラムを作成(後述)。


展開後のファイルを適当なディレクトリに置く


適当にディレクトリを掘って、リネーム用プログラムを置く


コマンドプロンプトから適当に実行


動けば正義、『.mp3』っていうファイル名のは諦めようｗ


変換できていない理由はファイル名がまずくて読み込めない、或いはID3を読めなかったのが原因かな


適当にファイル名を付け直してリネーム用プログラムに投げる
どうにもならないのは、_UNKNOWN_00.mp3とか適当にリネームしよう

『"Arpeggione Sonata" from Schubert's piano Sonata D. 821 1st. Allegro moderato』っていう曲はunicodeで入れてあるようだ、ぐぬぬ。


リネーム用プログラムは次のような感じで。

#include
#include
#include

bool getName(std::string& sNameNew, const std::string& sNameFile);

int main(int argc, char *argv[])
{
std::string sNameBefore;
std::string sNameAfter;


if (2 != argc)
return 1;

sNameBefore = argv[1];
if (!getName(sNameAfter, sNameBefore))
return 2;

if (!MoveFileEx(sNameBefore.c_str(), sNameAfter.c_str(), MOVEFILE_COPY_ALLOWED))
return 3;

return 0;
}

bool getName(std::string& sNameNew, const std::string& sNameFile)
{
ID3_Tag tag;
ID3_Frame *pFrame;
ID3_Field *pField;
char *p;


tag.Link(sNameFile.c_str(), true, false);
pFrame = tag.Find(ID3FID_TITLE);
if (NULL == pFrame)
return false;

pField = pFrame->GetField(ID3FN_TEXT);
if (NULL == pField)
return false;

if (NULL == pField->GetRawText())
return false;

p = new char[pField->Size() + 1];
if (NULL == p)
return false;

CopyMemory(p, pField->GetRawText(), pField->Size());
p[pField->Size()] = '\0';

sNameNew.erase();
sNameNew.append(p);
sNameNew.append(".mp3");

delete[] p;

return true;
}

グラナド・エスパダのBGMを抽出

IPF Extractorを使えばいいらしいけど、面白くないからある程度自力で。
とりあえず適当なC++開発環境と7-Zip、それとグラナド・エスパダのBGM格納ファイル(bgm.ipf)を用意しよう。
bgm.ipfはパスワード付きzipファイルなのだけど、パスワードの入力が厄介だからプログラムでクリップボードに入れてから張りつける。
プログラムについては後述。



7-Zipで展開


クリップボードに入れたパスワードをCtrl+Vで張りつける


エクスプローラと7-Zipでのファイル数確認、bgm.ipfそのもの+中身190個でファイル数:191


ファイル名が酷い


ID3からファイル名を取ってきたい


プログラムは次のような感じ、動けば正義。

#include

int main()
{
HANDLE hClipboard;
LPVOID pMemory;
DWORD size;
HGLOBAL hNewData;
static BYTE aPasswd[] =
{
0x25, 0x66, 0x20, 0x25, 0x66, 0x20, 0x25, 0x73, 0x20, 0x25, 0x73, 0x20, 0xff, 0xff, 0xff, 0xff,
0x3f, 0x5b, 0x20, 0xff, 0xff, 0xff, 0xff, 0x3f, 0x25, 0x66, 0x20, 0x25, 0x66, 0x20, 0x25, 0x73,
0x20, 0x68, 0x20, 0x25, 0x73, 0x20, 0x2e, 0x3f, 0x2e, 0x20, 0x20, 0x20, 0x58, 0xff, 0x24, 0x24,
0x00
};


OpenClipboard(NULL);
hClipboard = GetClipboardData(CF_TEXT);
if (NULL != hClipboard)
{
pMemory = GlobalLock(hClipboard);
size = GlobalSize(hClipboard);
hNewData = GlobalAlloc(GPTR, sizeof (aPasswd));
CopyMemory(PVOID(hNewData), aPasswd, sizeof (aPasswd));
GlobalUnlock(hClipboard);
EmptyClipboard();
SetClipboardData(CF_TEXT, hNewData);
}

CloseClipboard();

return 0;
}

lock-free queue

この辺を眺めていて適当に調べてみたけど、ダレた。

こんな感じのデータ構造を使うみたいだけど、

struct pointer_t
{
unsigned int count;
node_t *ptr;
};

struct node_t
{
val_t val;
pointer_t next;
};

struct queue_t
{
pointer_t head;
pointer_t tail;
};

queue_t::tail::ptr とかの先を参照してaccess violationを起こさない保証っていうのは、あるのだろうか。
enqueue毎にmalloc、dequeue毎にfreeするみたいだけど、malloc/freeの中の排他制御で結局は重くなりそうな気がする。
CPU数が16とか32くらいで効果が出てくるけど、2~4程度だと逆に重いらしく、自分で使えないから萎える。
何となくInterlockedCompareExchange64みたいなもの(戻り値が違う)を書いてみたけど、書いただけ。

; ml.exe /c /coff /Cx
.686
.MODEL FLAT, STDCALL
.CODE

;BOOL __stdcall cas64(ULARGE_INTEGER *pDst, ULARGE_INTEGER *pCompare, ULARGE_INTEGER *pExchange);
PUBLIC cas64
cas64 PROC, pDst:DWORD, exchange:QWORD, compare:QWORD

push ebp
mov ebp, esp

push esi
push ebx
push ecx
push edx

mov esi, DWORD PTR [ebp+0cH]
mov eax, DWORD PTR [ebp+10H]
mov edx, DWORD PTR [ebp+14H]
mov ebx, DWORD PTR [ebp+18H]
mov ecx, DWORD PTR [ebp+1cH]
lock cmpxchg8b QWORD PTR [esi]
mov ebx, 1
mov eax, 0
cmovz eax, ebx

pop edx
pop ecx
pop ebx
pop esi

pop ebp
ret 4+(8*2)
cas64 ENDP
END

職を選ぶということとか

・勤務地が地元(=実家近く)という縛り
・正社員であること、将来的に一家の大黒柱となる以上当然
・可能な限り好きな分野で働きたい、好きこそ物の上手なれって言うしね

好きでもない分野も含めて20社程度受けるけど落ちまくる＼(^o^)／
卒業後に職安で探して受けまくるけど、残念な結果。
仕方なくブラック派遣会社に顔を出すけど、

・名古屋に引っ越して鯖管やってくれ→無理っす
・クルマで片道2時間→無理っす っていうのが2件
・多重派遣→無理っす


仕方がない。