Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Changes Made to TAG.EXE (Read 162763 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Changes Made to TAG.EXE

2006-02-08 11:53 :
2.0.45 released.  As well as --tocue, --tocuen and --tocuea, I have now added the --paranoid switch which will cause warnings and non-critical errors to return a non-zero return code, so that this can be picked up in a script.  Thanks to R Hannes Beinert for the suggestion and patch.

2005-12-08 13:24 :
2.0.45b9:  Added code to fix memory leak.  Report and code kindly provided by Steve Vibert.

2005-12-08 13:24 :
2.0.45b8:  Added --tocue, --tocuen and --tocuea.  libVorbis 1.1.2 & libOgg 1.1.3.

2005-04-21 22:00 BST:
If you downloaded Tag 2.0.43 before 19:30 BST you may want to download it again.

See [a href='index.php?act=findpost&pid=292528']this post[/a] for more info.

2005-04-21:
Quote
a small bug report for 2.0.42. View APE 3.98 and higher files' tags and the details field is incorrect, for example: "Details: 24 Hz, playtime 42274:53:30". The 24 Hz part is always constant.

Version 2.0.43 has been uploaded.

v3.98+ APE files are now detailed correctly. Also, the 10KB limit when using the -f switch has been removed.

Update: wapet has also been updated now, so that the 10KB limit no longer applies.  wapet 0.5 available here.

2005-02-07:
I thought I may as well record on forum that I have updated Case's Tag with libFLAC 1.1.2.  You can get it here.

It now uses libFLAC 1.1.2, libOgg 1.1.2 and libVorbis 1.1.0 - all the most recent releases.

I see from the FLAC changelog that there have been some changes relevant to VORBIS tagging, so I thought I may as well.

Original Post:
This topic explains the history of this amendment

[a href='index.php?showtopic=25921']EAC+MAC+TAG+PAR2[/a]

There is a little information, and all the downloads here:

http://synthetic-soul.co.uk/tag/

I hope someone else finds this useful as well.

wapet  is also now available, with the additional -f switch.
I'm on a horse.

Changes Made to TAG.EXE

Reply #1
Thanks for this.  Tag is for me an incredibly useful tool and these are two valuable enhancements.  I have tested both changes and in general they look good.

I have however come across one bug with the file-based tagging: I tried to load into a tag a file that contained a British pound sign (£).  This seemed to work but when I then view the tags using Tag it doesn't show the pound sign.  And if I load the file into foobar2000 it doesn't show that tag at all.

I did some testing and found that if I write the tag using foobar2000 it adds two bytes to the file for that character rather than one.  The first byte is hex C2, the second is hex A3 which corresponds to the £ sign.  So for some reason it adds that additional byte before the £ sign (but doesn't display it when viewing the tag).  I also found that when Tag.exe adds a tag containing a £ sign using the -t method it also adds this additional A3 byte.  So it is only the file loading method that is not doing this.

Of course I don't know that this issue is specific to £ signs, but so far that's the only character I've found that triggers it.  Also I've only tested this on OptimFrog .ofr files with APEv2 tags so far, so it may not be an issue with other file or tag types.

Changes Made to TAG.EXE

Reply #2
Thanks for the feedback phwip.

I will investigate this.

I am a little confused as I let the existing Tag code deal with all the complex bits.  If I may I would like to take this opportunity (as I'm sure it will come up again)  to explain how the file loading bit (-f) works, in comparision to setting an absolute value (-t)

The -t switch code:
  • looks for the switch
  • checks that there is a following parameter
  • adds the whole parameter ("<tag>=<value>" hopefully) to the tags collection
The -f switch code:
  • looks for the switch
  • checks that there is a following parameter
  • checks the parameter is of format "<tag>=<file>"
  • strips out the filename (<file>)
  • checks the file exists
  • begins a 'string' with "<tag>="
  • reads through the file and appends all characters to the string in turn
  • adds the new string ("<tag>=<value>") to the tags collection
All the clever stuff is still done by Case's code - I'm just intercepting a "<text1>=<text2>" parameter, swapping it with "<text1>=<text3>", and then letting it carry on down the road.

I can only assume this is another weird side of reading character by character from the text file (as per the disappearance of any carriage returns).

I will definately try to resolve this.  I'm still waiting for a competent C++ developer to give me some pointers...
I'm on a horse.

Changes Made to TAG.EXE

Reply #3
I've tested this a little further with APEv2, APEv1 and ID3v1 tags, all against mp3 files this time.

If I tag using the switch -t artist=a£b and then force one of the above tag types, all of the files then correctly show the artist as a£b when viewed via foobar2000 or Tag itself.  If I view the files with a hex editor the ID3v1 and APEv1 tags are both internally stored as 61 A3 62 which are the corresponding codes for a£b.  The APEv2 tag is stored internally as 61 C2 A3 62.

However, if I use the switch -f artist=test.txt where test.txt contains the single line a£b then all the files show the artist as ab when viewed by Tag, and the same with foobar2000 except for the APEv2 tagged file for which foobar2000 does not see an artist tag at all.  In a hex editor I see that the ID3v1 and APEv1 tags are stored as 61 62 and the 61 A3 62.

So the problem affects all three tag types although the internal storage method is slightly different for APEv2 tags than the other two.

I hope this is useful information.

Changes Made to TAG.EXE

Reply #4
I'm pretty sure I've resolved this now.

The -t switch parameters were getting converted to UTF8 from UNICODE immediately, and then passing a flag saying they were UTF8.

My -f switch parameters were passing the flag, but had not been converted.

I have stopped them setting the flag, so they are now converted to UTF8 just before they are written.

I have tried a few different file types, and ID3v1 and APEv2, and I get no problem now.

I would quite like to have a test string with more test characters than "£" - but as I am pretty sure that this was the problem I am equally sure that any similar issues would have been resolved.  I don't understand enough about UNICODE and UTF8 to know offhand.
I'm on a horse.

Changes Made to TAG.EXE

Reply #5
Excellent.  Overcomes the problem for all the tag types I tested (ID3v1, APEv2 and APEv1).  Thanks.

Changes Made to TAG.EXE

Reply #6
Good news.

I'm hoping to get chance to test out the whole cycle tonight:

EAC -> MAREO -> MAC /  TAG / PAR2

I'll be interested to see how it goes...  I'm sure it will go smoothly... 

Thanks for your support phwip - please let me know if you find any other problems.

[span style='font-size:8pt;line-height:100%']Edit: added link to the guide I wrote subsequently.[/span]
I'm on a horse.

Changes Made to TAG.EXE

Reply #7
I thought I may as well record on forum that I have updated Case's Tag with libFLAC 1.1.2.  You can get it here.

It now uses libFLAC 1.1.2, libOgg 1.1.2 and libVorbis 1.1.0 - all the most recent releases.

I see from the FLAC changelog that there have been some changes relevant to VORBIS tagging, so I thought I may as well.
I'm on a horse.

Changes Made to TAG.EXE

Reply #8
Hello!

This program is really useful for creating playlists. However, I can't find a list of tag types for use with the --force <tag> command. I want to force tag.exe to read ID3v2 instead of ID3v1 as it seems to do by default. I tried --force ID3v2 but it didn't recognized the tag type.
Thanks in advance for your help.

Changes Made to TAG.EXE

Reply #9
Hi Synthetic Soul,

a small bug report for 2.0.42. View APE 3.98 and higher files' tags and the details field is incorrect, for example: "Details: 24 Hz, playtime 42274:53:30". The 24 Hz part is always constant.

Thanks for the much-needed updates.

Quote
I tried --force ID3v2 but it didn't recognized the tag type.

Tag does not write ID3v2 tags, it only reads them.

Cheers,
CD

Changes Made to TAG.EXE

Reply #10
Quote
This program is really useful for creating playlists.
Please bear in mind the original program, which still accounts for 99% of this version, was written by Case.  I have only added the -f switch and updated the libraries.  He da man!

Quote
I can't find a list of tag types for use with the --force <tag> command. I want to force tag.exe to read ID3v2 instead of ID3v1 as it seems to do by default. I tried --force ID3v2 but it didn't recognized the tag type.
I believe that --force is for writing only.  I don't think you can tell Tag to display the tags from a certain format, but I may be wrong.

NB: Acceptable values for --force are:
  • ID3v1
  • APE
  • APE1
  • APEv1
  • APE v1
  • APE2
  • APEv2
  • APE v2
  • Ogg
  • Vorbis
  • FLAC
  • Lyrics

Quote
a small bug report for 2.0.42. View APE 3.98 and higher files' tags and the details field is incorrect, for example: "Details: 24 Hz, playtime 42274:53:30". The 24 Hz part is always constant.
Please see my response to Cutter - I have made no changes to this area.  I have tested with Tag 2.0.39, Case's last version, and this reports the files as 24Hz also - which is unsurprising to me, as I have been nowhere near that code.

I don't understand enough in this area to try to explain I'm afraid.  I have done a little investigation (I'm bored) and it does seem the APE header reading is a little lacking - a lot more information (e.g.: bitrate, channels) is attempted to be read and output, but only the frequency and playtime appear to make it through.  On the few files I've checked the playtime is also wrong.

Edit: Thinking about it, I guess this may be because the header format has changed since Tag was last worked on by Case (April 2003).  At this time I believe 3.97 was the latest version - 3.98a1 wasn't released until May 2003.  Maybe someone can confirm this.  Unfortunately I am not skilled enough to update the code. 
I'm on a horse.

Changes Made to TAG.EXE

Reply #11
Any chance of adding support for the removal of specific tags?  Currently only all tags can be removed or just ID3v2 from MP3s.  TIA

Changes Made to TAG.EXE

Reply #12
To remove an individual tag in Tag just use:

TAG.EXE -t COMENT= MyFile.ext

The above command will remove the COMENT tag completely from the file MyFile.ext (by simply specifying nothing after the equals sign).

If your tag had spaces you would need to use:

TAG.EXE -t "MY COMENT=" MyFile.ext
I'm on a horse.

Changes Made to TAG.EXE

Reply #13
Quote
a small bug report for 2.0.42. View APE 3.98 and higher files' tags and the details field is incorrect, for example: "Details: 24 Hz, playtime 42274:53:30". The 24 Hz part is always constant.

Version 2.0.43 has been uploaded.

v3.98+ APE files are now detailed correctly.

Also, the 10KB limit when using the -f switch has been removed.
I'm on a horse.

Changes Made to TAG.EXE

Reply #14
Quote
Quote
a small bug report for 2.0.42. View APE 3.98 and higher files' tags and the details field is incorrect, for example: "Details: 24 Hz, playtime 42274:53:30". The 24 Hz part is always constant.
Please see my response to Cutter - I have made no changes to this area.  I have tested with Tag 2.0.39, Case's last version, and this reports the files as 24Hz also - which is unsurprising to me, as I have been nowhere near that code.

I don't understand enough in this area to try to explain I'm afraid.  I have done a little investigation (I'm bored) and it does seem the APE header reading is a little lacking - a lot more information (e.g.: bitrate, channels) is attempted to be read and output, but only the frequency and playtime appear to make it through.  On the few files I've checked the playtime is also wrong.

Edit: Thinking about it, I guess this may be because the header format has changed since Tag was last worked on by Case (April 2003).  At this time I believe 3.97 was the latest version - 3.98a1 wasn't released until May 2003.  Maybe someone can confirm this.  Unfortunately I am not skilled enough to update the code. 

The problem was, as suggested in my edit, that 2.39 knew nothing about the new APE header format.

I have persevered and, in contradiction to my post above, I was just skilled enough to make the changes.
I'm on a horse.

Changes Made to TAG.EXE

Reply #15
When trying to download 2.0.43 I get a 404...

Changes Made to TAG.EXE

Reply #16
Sorry - should be there now.
I'm on a horse.

Changes Made to TAG.EXE

Reply #17
wapet has also been updated now, so that the 10KB limit no longer applies.

wapet 0.5 available here.
I'm on a horse.

Changes Made to TAG.EXE

Reply #18
If you downloaded Tag 2.0.43 before 19:30 BST you may want to download it again.

I discovered an issue in Case's original code that resulted in screwy bitrate values being reported on long files (e.g.: a CD image).

To resolve I changed the line:

Code: [Select]
(Info->Details.Duration > 0)  ?  (long)(Info->FileSize * 8 / Info->Details.Duration + 500) / 1000  :  0;

... to:

Code: [Select]
(Info->Details.Duration > 0)  ?  (long)(((signed __int64)Info->FileSize * 8 / Info->Details.Duration) + 500) / 1000  :  0;

..which correctly results in, e.g., 859 kbps, not 4294966745 kbps.

I can only assume this is some sort of overflow bug, which is why I added the (signed __int64).  Maybe someone has a more elegant solution.

Sorry, I was testing on track files, so didn't notice earlier.
I'm on a horse.

Changes Made to TAG.EXE

Reply #19
Quote
I can only assume this is some sort of overflow bug, which is why I added the (signed __int64).  Maybe someone has a more elegant solution.

Right, the code overflows when the file size is over 512MB. Your solution is elegant enough, though not portable (I'm not sure if it's meant to be, but it will compile on MSVC++, but not gcc).

Changes Made to TAG.EXE

Reply #20
was gcc used to compile TAG before?

Changes Made to TAG.EXE

Reply #21
tag 2.0.43 reports the correct bitrate for APE files. Thank you, Synthetic Soul

Changes Made to TAG.EXE

Reply #22
Quote
Right, the code overflows when the file size is over 512MB. Your solution is elegant enough, though not portable (I'm not sure if it's meant to be, but it will compile on MSVC++, but not gcc).

Thanks for the confirmation Supernaut - it's good to have my code scrutinised by a competent C++ programmer.  If you know any of the story behind this you'll know I don't count myself in that group.

Quote
was gcc used to compile TAG before?

The original source from Case has MSVC++ workspace/project files - so I think it's always been MSVC++.  I'm using 6, not .NET/7 (although I have both).

Edit: also, the reason I tried (signed __int64) was that Case had used it one or two lines previous.  So I guess that confirms it has always been MSVC++ only.

Quote
tag 2.0.43 reports the correct bitrate for APE files. Thank you, Synthetic Soul

No problem.  Ever since you mentioned it it's bugged me, but I have just really struggled working out the new APE header.

Edit: Example of improvements:

C:\DOS>tag *.ape
Tag - Automatic Tag from filename
Copyright © 2002-2003 Case.  Minor additions by Neil Popham, 2004-2005
Version 2.0.43, Compiled 2005-04-21

C:\DOS\cdimage.ape
Format:  Monkey's Audio 3.99 (High)
Details: 44100 Hz Stereo, 808 kbps, playtime 49:19
File has no known tags.

C:\DOS\cdimage397.ape
Format:  Monkey's Audio 3.97 (Normal)
Details: 44100 Hz Stereo, 817 kbps, playtime 49:19
File has no known tags.


C:\DOS>tag-2.0.39 *.ape
Tag - Automatic Tag from filename      Copyright © 2002-2003 Case
Version 2.0.39b, Compiled 2003-04-11

C:\DOS\cdimage.ape
Format:  Monkey's Audio 3.99
Details: 24 Hz, playtime 1060:01:46
File has no known tags.

C:\DOS\cdimage397.ape
Format:  Monkey's Audio 3.97
Details: 44100 Hz Stereo, 4294966663 kbps, playtime 49:19
File has no known tags.
I'm on a horse.

Changes Made to TAG.EXE

Reply #23
Rename From Tag Then Tag From Filename
Code: [Select]
@ECHO OFF
Echo Generate Filenames (Test)
Pause
C:\progra~1\tag\tag.exe --rentag --itemfix -t Comment= --test --trackinc --zeropad --scheme "N - A - L [Y] - T" *.mp3 --recursive
ECHO Do Same Without Testmode
pause
C:\progra~1\tag\tag.exe --rentag --itemfix -t Comment= --trackinc --zeropad --scheme "N - A - L - T" *.mp3 --recursive
C:\progra~1\tag\tag.exe --rentag --itemfix -t Comment= --trackinc --zeropad --scheme "N - A - L [Y] - T" *.mp3 --recursive
Echo Generate Tags (Test)
pause
C:\progra~1\tag\tag.exe --auto --test --caps --spacefix --removeid3v2 --force apev2 --trackinc --zeropad --autoscheme *.mp3 --recursive
ECHO Do Same Without Testmode
pause
C:\progra~1\tag\tag.exe --auto --removeid3v2 --caps --spacefix --force apev2 --trackinc --zeropad --autoscheme *.mp3 --recursive
pause


Tag From Filename Then Rename From Tag
Code: [Select]
@ECHO OFF
Echo Generate Tags (Test)
pause
C:\progra~1\tag\tag.exe --auto --test --caps --spacefix --removeid3v2 --force apev2 --trackinc --zeropad --autoscheme *.mp3 --recursive
ECHO Do Same Without Testmode
pause
C:\progra~1\tag\tag.exe --auto --removeid3v2 --caps --spacefix --force apev2 --trackinc --zeropad --autoscheme *.mp3 --recursive
Echo Generate Filenames (Test)
Pause
C:\progra~1\tag\tag.exe --rentag --itemfix -t Comment= --test --trackinc --zeropad --scheme "N - A - L [Y] - T" *.mp3 --recursive
ECHO Do Same Without Testmode
pause
C:\progra~1\tag\tag.exe --rentag --itemfix -t Comment= --trackinc --zeropad --scheme "N - A - L - T" *.mp3 --recursive
C:\progra~1\tag\tag.exe --rentag --itemfix -t Comment= --trackinc --zeropad --scheme "N - A - L [Y] - T" *.mp3 --recursive



Thanks for making such a great command line tool! The batch files above are by far the easiest way for me to tag and rename my mp3 collection! I just drop the appropriate one into my music subdirectory and run it! There are several other things you could do to....but this is the easiest. Just make sure to include your filename scheme at the TOP of the tag.cfg auto-guesser section, and change the options above to match your tag.exe location and filename scheme.

If the author would allow a way to edit tags and/or filenames using general expressions, that would be very much appreciated! (i.e. remove everything in parentheses, and everything after and including feat., ft., ft, feat, etc.). If anyone has a way to do this as of now, please fill me in! Also, could you explain what trackinc does? I thought it was an auto-track numbering switch, but it doesn't seem to do that. That ability would be very much appreciated! Thanks!

Changes Made to TAG.EXE

Reply #24
Following a request from [proxima] I have made some amendments to Tag.
Quote
Code: [Select]
 --tocue <scheme>  : output cuesheet tag to file, name generated from <scheme>
 --tocuen <name>   : output cuesheet tag to file <name>
 --tocuea          : output cuesheet tag to file, name generated from source

<snip>

Outputting cuesheets:
---------------------
You can output the contents of an embedded cuesheet to file using one of the
--tocue switches.

To output the content to a file whose name is detirmed by tag values:

  Tag --tocue "%A - %L" <files>

To output the content to a specific file:

  Tag --tocuen "C:\My Music\CDImage.cue" "C:\My Music\CDImage.wv"

To output the content to a file with the same name as the source:

  Tag --tocuea <files>

If the file is "C:\CDImage.wv" the cuesheet will be called "C:\CDImage.wv.cue"

By default, using --tocue and --tocuea will overwrite existing files,
but --tocuen will append to an existing file.  To make --tocuen overwrite use
the --overwrite switch (hack).
It's still in beta so I haven't added it to the page yet, but I thought I'd let people know, to maybe get some feedback.  You can download it here.

Thanks to [proxima] for the idea, and feedback.

I hope some others find it useful.

NB: [proxima] did ask whether Tag could amend the FILE reference to point to the audio file where necessary. This is unfortunately beyond my C++ skills (which are 50% copy'n'paste and 50% basic syntax).  I am hoping that David will implement this in WavPack (as discussed in another thread) and then I can plagiarise his code.  I can't believe there is no easy-looking way of using regular expressions with C/C++ (Tag really seems to be C syntax from my limited experience).

Edit: @ [proxima]: Again, thanks for your help. FYI: Since Beta 5 I am no longer using the --tofile code, so:

TAG --tocuea --recursive *.wv

... works. 


Edit: Updated link to beta 9
I'm on a horse.