K_Meinhard wrote:
| Hallo Rex,
|
| is there a chance that TCC will support file tags for e.g. mp3 and jpg
| files in the foreseeable future?
|
| Explorer can show a lot of them, and I find the ability to sort
| according to a tag useful (renaming my holiday pictures according to
| shooting date, not copy or changed date, for example).

I name my pictures by shooting date and time, e.g., 200806\16210520.jpg =
2008-06-16 @21:05:20.
--
Steve

I have a TCC batch program that searches the virtual drives where the camera
or its SD card may be plugged in for .JPG and .MOV files, and use
%@filedate[] and %@filetime[] of the files as created by the camera to copy
them under the new name. Once the filedate and filetime are used to provide
the name for the file, any subsequent processing or copying would not
accidentally change the filename, remaining a reliable tag.

Another alternate would be to use the DESCRIBE command. If you use NTFS, you
can select stream descriptions. BTW, is "tag" available for non-NTFS file
systems?

I don't know what you refer to when you mention mp3. Your OP related to
pictures only; this would be an extension of your original question.

BTW, how does the á (lower case "a" with acute accent) character in my name
become capital X in your response? Your responses are the only place where
this happens.
--
Steve

> I have a TCC batch program that searches the virtual drives where the
> camera or its SD card may be plugged in for .JPG and .MOV files, and
> use %@filedate[] and %@filetime[] of the files as created by the
> camera to copy them under the new name. Once the filedate and
> filetime are used to provide the name for the file, any subsequent
> processing or copying would not accidentally change the filename,
> remaining a reliable tag.

Yeah, if you have access to the original files on card. Here, I have to
concatenate pictures from different cameras I receive e.g. on CD.
Working with the tagged info in that pictures would decidedly be nice.

> I don't know what you refer to when you mention mp3. Your OP related
> to pictures only; this would be an extension of your original
> question.

At this moment I'd like the ability to sort a directory according to
internal tags like shooting date for jpg files, artist or album for mp3
files, bitrate for video or music files might be another one. I can then
direct the output of the dir command to a file and work from there.
Adding the ability to other file commands like copy, move and del
wouldn't hurt. Could ranges be adapted to this?

Iff the dir command is too complicated as is already, pdir would do just
as well. Anything that allows to read internal tags and sort files
according to these.

I don't use file descriptions any more, since LFNs are enough for my
purposes. But if I can get internal tags into files descriptions, i can
get them into LFNs.

More enterprising still: interaction between the TCMD List View window
and TCC would be nice: show the internal file tags optionally as in
Explorer, sort according to these by clicking on the columns header, and
the DIR command off TCC automatically inherits these settings :-)

Filetags are essentially internal file descriptors, and the one of teh
major purposes of TCC is handling files. I think the handling of
filetags should be an internal to TCC.

BTW, externals are unreliable: e.g. F. Romano's FEDUTILS were written
for version 7 and don't work well with version 9. You are dependant on
the (freeware) authors will and ability to adapt his plugin to the
changing TCC.

Explorer displays only a small subset of the tags available in these and
similar file types.

While you require only the "Date Taken" tag, others may need any of the
many other available tags. The scope of your request is much larger than
what you may initially think.

I suggest you do a little more research of you own on the subject of
"Exif tags" to gain a better understanding of what is involved.

I recommend "Exiftool by Phil Harvey". As well as the Perl Library
mentioned by Josh below there is also a Windows Command line executable
package. This, however, may be overkill for what you need and a less
comprehensive tool like "id3" (mentioned below) or similar might suit
you better.

Filetags are essentially internal file descriptors, and the one of teh
major purposes of TCC is handling files. I think the handling of
filetags should be an internal to TCC.

BTW, externals are unreliable: e.g. F. Romano's FEDUTILS were written
for version 7 and don't work well with version 9. You are dependant on
the (freeware) authors will and ability to adapt his plugin to the
changing TCC.

However, I still think that conceptually a plugin is a better way to do it. That way, JPSoft itself could write the plugin for very popular items (mp3 tags, exif headers, etc) while still leaving room for others to fill in the gaps for less popular items. The plugin model also allows JPSoft to have a standard way of doing something, but allow for individual creativity and expansion. In other words, if I don't like the JPSoft way of handling tags I can replace it myself or with a third party option. All of this assumes a robust plugin framework of course. Since I've yet to try my hand at plugin development for TakeCommand/TCC, I have no idea how difficult this is.

I guess I'm just a firm supporter of modularity wherever possible. A monolithic TakeCommand holds little appeal to me. In general, I would be opposed to blithely adding commands, functions, variables to the core functionality that could easily be provided by a plugin. I think such an approach generally lends itself to cleaner more bug free code.

I see a standalone executable that repeats much of what is inbuilt in
TCC. The size of that executable is about 87 Kb. If supporting all tags
is too much to ask, one could take a hint from Explorer selectionwise
:-)

> I guess I'm just a firm supporter of modularity wherever possible. A
> monolithic TakeCommand holds little appeal to me. In general, I
> would be opposed to blithely adding commands, functions, variables to
> the core functionality that could easily be provided by a plugin. I
> think such an approach generally lends itself to cleaner more bug
> free code.

That is a basic design decision. There are things in TCC now that could
be put into a plugin, and I don't care overmuch how something is
implemented, as long as it works. But my guess is that the support
problems are so much greater than with a "unified" TCC, and Rex will
prefer that.

Externals exist for much of what TCC has added over the years. There are
e.g. 6 hash functions for files implemented. Why these and not tags? I
repeat my opinion: TCC should be able to recognize and at least read
filetags, to use in sorting, renaming etc. If the ability to write is
included, so much the better.