Recent comments posted to this site:

http://projects.iq.harvard.edu/fits might be an even better choice than libextractor. We use it in work and its not too bad, but it can be slow to startup due to the JVM.

The arm binaries are ARMv6; they're built on a Debian armel system.

Obviously there is a lot of variation in ARM instructions sets. Like Debian, we're shooting for lowest common denominator here.

(Note: I'm going to be moving your comment and this one to the place you should have posted it...)

Comment by http://joeyh.name/ Wed Feb 26 21:07:20 2014
I'm trying to run git-annex on my Raspberry PI, which is an ARMv6 device. But I can't tell if the prebuilt binaries are ARMv6 or ARMv7. The binaries seem to work, but it's not clear to me how early I should expect things to fail if they're compiled for ARMv7.

@mebus : You can put your SSH keys here :

/sdcard/git-annex.home/.ssh/id_rsa

/sdcard/git-annex.home/.ssh/id_rsa.pub

comment 1 307898855f91a2a189d4fa5eae62cce1
[[!comment Error: unsupported page format txt]]
Tue Feb 25 20:42:38 2014

actually in your mp3 example you could have ....

ATTRIBUTE=sample_rate, VALUE=22100, UNIT=Hertz

another example use case is to always be consistent with the AVU order then you could stick in ntriples from RDF to do other cool things by looking up various linked data sources -- see http://www.w3.org/2001/sw/RDFCore/ntriples/ and http://www.freebase.com/, actually this would be quite cool if git-annex examined the mp3's id3 tag, the created an ntriple styled entry can be automatically parsed with the web-based annex gui and automatically pull in additional meta-data from the likes of freebase. I guess the list of ideas can just only get bigger with this potential metadata capability.

Some additional ideas for metadata...

Instead of having a simplistic scheme like 'field=value' it might be advantageous to consider a scheme like 'attribute=XXX, value=YYY, unit=ZZZ' that way you could do intesting things with the metadata like adding counters to things, and allow for doing interesting queries like give me all 'things' tagged with a unit of "audio_file", this assumes one had trawled through an entire annex and then tagged all files based on type with the unix file tool or something like that.

The above idea is already in use in irods and its a really nice and powerful way to let users add meta-data and to build up more interesting use cases and tools.

btw, I plan on taking a look at seeing if I can map some of the meta that we have in work into this new git-annex feature to see how well/bad it works. Either way this feature looks cool! +1!!!

Hi,

I love the idea behing storing metadata.

I suggest to exchange ideas (and maybe code) with projects already implementing metadata systems.

I have tried several implementations and particularly noticed tmsu (http://tmsu.org/). This tool stores tags into a sqlite database and uses also a SHA-256 fingerprint of the file to be aware of file moves. It provides a fuse view of the tags with the ability to change tags by moving files (like in the git annex metadata view).

Paul Ruane is particularly responsive on the mailing list and he already supports git annexed files (with SHAE-256 fingerprint) (see the end of the thread https://groups.google.com/forum/#!topic/tmsu/A5EGpnCcJ2w).

Even if you cannot reuse the project, they are interresting ideas that might be worth looking at like the implications of tags: a file tagged "film" being automatically tagged "video".

Tagsistant (http://www.tagsistant.net/) may also be a good source of inspirations. I just don't like the fact that it uses a backstore of tagged files.

Thanks for reading.

Yeah, I choose no encryption for this one for worst case scenario reasons (I still want photos of my kid even if I loss my gpg key and my house burns down). Now about setting up http://git.kitenet.net/?p=gpg.git;a=blob;f=README.sss;hb=HEAD ......
Comment by http://grossmeier.net/ Fri Feb 21 17:53:02 2014
comment 5 8789fc27466714faa5a3a7a6b8ec6e5d
[[!comment Error: unsupported page format txt]]
Fri Feb 21 17:12:52 2014
Comments on this page are closed.