Is there a faster way to enter in files in the anidb database?
Everytime I add a new file, I have to enter in the CRC,SHA and MD5 (which I have to hash myself), the size of the video, group released, audio type, video type etc.
A faster way to enter in files?
Moderator: AniDB
To be more specific: If you hash the file with AOM, the following entries will be set a by an automatic change-request:
... and especially when mass-adding files, I always use this lazy way ^^
- sha
- md5
- crc
- video-height
- video-width
... and especially when mass-adding files, I always use this lazy way ^^
Re: A faster way to enter in files?
Indeed. Not even g-spot can atm. AOM 0.6 might have extra support (/me sticks the boot in peli-tan), but for the moment scrabbling what you can from the player is best bet.Jelsoft (on AR) wrote:I gave the program a try.
The program can hash files with no problem, but it can't get the codec, size and length of mkv files.
Rar
first of all... please don't add the file size manually.. the file size will be filled in automatically if you provide the ed2k link (note the 'may be left blank if ed2k link is provided.' next to the file size field)
second of all.. to get the codec info including the bitrates of .ogm and .mkv files, you have to use Virtual Dub Mod, open the file and check under File Information
second of all.. to get the codec info including the bitrates of .ogm and .mkv files, you have to use Virtual Dub Mod, open the file and check under File Information
For MKV-Files, there's also the Matroska Prop program. It adds a few tabs to an MKV-File's property window in Windows Explorer. At the moment, it can display the codec type, video size, framerate, play length and several other bits and pieces of information just fine, but it unfortunately fails to calculate the bitrate. At least on my system, it only produces a dialogbox that reports that an unhandled exception has been caught - in other words, it messed up and almost crashed. (But kudos to the programmers for handling uncaught exceptions in the end rather then let explorer just die a horrible and painful death...)