SFV extensions

[NoMo]

Hello,

I am a regular user of SFV/CSV and would like to know if there are more of you out there and think SFV generation is to narrow.
Like with the CSV, in order to check the files I always have to use Ultraedit->macros to convert them to the SFV standard.
Or In the CSV the subdirectories are also included.

I myself would like it VERY much to have the possibility to add the comments from the descript.ion in the SFV-files.

[ghisler(Author)]

TC is following the SFV 1.0 standard, which doesn't include any size or date information. Do you have any information about this extension?
- what SFV version is needed to handle them?
- what is the exact syntax?
- how does the date handle regional settings? Americans write the date differently than Europeans or Japanese people.

[NoMo]

Hello again,

I am very sorry for the late reaction, I have been changing providers.

Here are 2 examples of the CSV-files I get delivered:

abraxsis_0001.jpg,556100,C1FF13AB,Victoria Poyser,Red as Blood
filename,filesize,CRC,artist,title

and:
boris_vallejo_bw_002.jpg,148846,4356F8A1,\Boris Vallejo\Black & White\,
filename,filesize,CRC,subdirectory,

[ghisler(Author)]

These are not SFV files. CSV is something completely different - it's a comma delimited file format for importing into Excel or similar programs.

[MxxCon]

i know it's not exactly on topic, but just wanted to comment..
i do use sfv files quiet extensively, but slowly converting to PAR/PAR2. sometimes even w/o creating recovery files simply becuase checking integrity with PAR/PAR2 seems to be much faster..

[NoMo]

As far as I can see now CSV is a very popular way of checking the integrety of files global. Would it than not be an idea to add A CSV feature or maybe switch to it?

As discribed above I now have to convert every CSV to an SFV format.
And when I want to deliver my own SFV it is not very much used and requests of CSV's are very frequent. So I need to fing another program to do just that. So far I only found check tools and not generation tools like the great feature implemented in tcmdr.

Thank you for considering my feature.

[milan_va]

I need a program to check another type of file signature, called a TTH root. I understand it's pretty rare, so I thought about new plugin type and a plugin. Another plugin of this type could do the *.CSV you are talking about.

The plugin interface could be quite simple, just
a) get a root path and relative filename and return a line of text and
b) get a root path and a line of text and return the filename (or check it at once)
c) return file extension (?)
Or I believe so.

Does anyone else think this plugin (type) would be used widely ?

Milan

--
For explanation of tree hashes go to http://www.open-content.net/specs/draft-jchapweske-thex-02.html, chapter 1 and 2.
Tiger hash is standardized, for implementation see http://www.cityinthesky.co.uk/delphi.html .

[milan_va]

Hello again.

I was thinking about it and noticed that "sfv" plugin could be joined with the "search" plugin suggested last september or so. The merged plugin would be named like "metadata plugin" and in search, you could specify a value this plugin gives. To sum up:
1) A plugin returns names and types (String, Int64) of data it returns.
2) In search, you could specify a plugin, it's function and value pattern (string) or range (integer).
3) When making a .sfv file, you could choose a predefined line format or define your own.

Example for 2: [std.size]>10000, [mp3.artist]="*Jean*"
Example for 3: [std.name] [std.crc32] (for .sfv)
or [std.name],[std.size],[std.crc32],[std.path] (for .csv ver 2)
or [tth.root] [std.name] (for .tth)

It would be fun to search for files by their md5sum, don't you think?

Milan

[Hammillian7]

I'm not sure wether this is the place to suggest it, but what I'm looking for is something like this:
+ When I command a .sfv file generation, I get a file containing the combined info of the current .lst plus the CRC. Suppose its named .lfv (whatever name the implementor chooses).
+ I can get inside the .lfv as inside a packer (like with the current .lst).
+ (new and seeked) I can command "Syncronize Directories) and "compare by contents" and this one calculates the CRCs of the other pane and compares them with the .lst ones, giving the result as if it had compared their true contents.
+ The previous point extended to comparison between two .lfv packs entered into on the 2 TC panes.
+ When I'm inside that pack, the contents of each file is represented by its CRC and this is what is compared when choosing, for example, "File, Compare by contents".
(or maybe in a lightly different implementation)

That's to say, I would like the current .lst packs to include the CRC of each file, representing its contents, and that the main tools for comparison by contents (the one under the "File" menu and the "Sycronize Directories") use the CRC for that comparisons, both between entries inside a .lst and between these ones and normal plain files.

Or should I start a new poll for this request?