How to tag all your audio files in the fastest possible way
Okay, the latest version of Pmusic (2.5.0) displays the filenames correctly. I tried tagging the files but I'm not sure it worked.
First, I installed Pmusic 2.5. Then I opened Pmusic from Menu -> Multimedia (may I suggest that the version - 2.5.0 in this case - be added to Pmusic's name in the title bar of the GUI?) Pmusic took several seconds to open. That's surprising, since it is such a small program and my multisession Puppy runs entirely in RAM. The first time I tried to open Pmusic, the delay made me think it wasn't going to open.
In the left pane of Pmusic, I navigated to the directory where the files were (in this case, /tmp/Carlson, Ron/The Signal, where there were 79 mp3 files), by clicking the double-dot thing at the top of the list, then clicking the appropriate directories. Everything looked good to Tag all tracks in list, so I clicked on that option in the drop-down Music sources menu. You can see in the screenshot how I filled out the blanks.
Pmusic took a while to tag all 79 files. When that was finished, I clicked the + Add all option in Pmusic's Music-sources drop-down menu, to add the tracks to the playlist. As you can see from the second screenshot, the first file is actually named 2 - 79. There is no 1 - 79. Is this because of the double-dot thing at the top of the left list? I confirmed that the track that was tagged 2 - 79 is actually the file named 01 - 79 by playing it.
Gxine used to show the id3 info for the track, but neither Mplayer nor ogle do, so I looked at the second file (02 - 79) with id3info:
It doesn't look like Pmusic tagged the file.
First, I installed Pmusic 2.5. Then I opened Pmusic from Menu -> Multimedia (may I suggest that the version - 2.5.0 in this case - be added to Pmusic's name in the title bar of the GUI?) Pmusic took several seconds to open. That's surprising, since it is such a small program and my multisession Puppy runs entirely in RAM. The first time I tried to open Pmusic, the delay made me think it wasn't going to open.
In the left pane of Pmusic, I navigated to the directory where the files were (in this case, /tmp/Carlson, Ron/The Signal, where there were 79 mp3 files), by clicking the double-dot thing at the top of the list, then clicking the appropriate directories. Everything looked good to Tag all tracks in list, so I clicked on that option in the drop-down Music sources menu. You can see in the screenshot how I filled out the blanks.
Pmusic took a while to tag all 79 files. When that was finished, I clicked the + Add all option in Pmusic's Music-sources drop-down menu, to add the tracks to the playlist. As you can see from the second screenshot, the first file is actually named 2 - 79. There is no 1 - 79. Is this because of the double-dot thing at the top of the left list? I confirmed that the track that was tagged 2 - 79 is actually the file named 01 - 79 by playing it.
Gxine used to show the id3 info for the track, but neither Mplayer nor ogle do, so I looked at the second file (02 - 79) with id3info:
Code: Select all
# id3info 02\ -\ 79.mp3
*** Tag information for 02 - 79.mp3
*** mp3 info
MPEG2/layer III
Bitrate: 8KBps
Frequency: 22KHz
#
- Attachments
-
- Pmusic Tag all tracks entries.png
- (28.14 KiB) Downloaded 527 times
-
- Pmusic playlist after tagging all files.png
- (53.96 KiB) Downloaded 480 times
Flash
Great report - we are very close now
I see the problem with starting count by 2.
That should be fixed in the func_id3tagger attached. Replace it with the one in /usr/local/pmusic/.
Look for the section - metadata.
I don't know what version ffmpeg prefers of the id3-standard (which isn't any standard at all). It could be the extended version 1, which is probably not supported by id3info. Please post the ffmpeg output, and it could maybe give some answers....
Sigmund
Great report - we are very close now
I see the problem with starting count by 2.
That should be fixed in the func_id3tagger attached. Replace it with the one in /usr/local/pmusic/.
It sure did. That is what we see in the playlist in your screenshot. To verify, you can see that tags by the commandIt doesn't look like Pmusic tagged the file.
Code: Select all
ffmpeg -i "file"
I don't know what version ffmpeg prefers of the id3-standard (which isn't any standard at all). It could be the extended version 1, which is probably not supported by id3info. Please post the ffmpeg output, and it could maybe give some answers....
Sigmund
- Attachments
-
- func_id3tagger.gz
- (1.75 KiB) Downloaded 366 times
Code: Select all
# id3info 02\ -\ 79.mp3
*** Tag information for 02 - 79.mp3
*** mp3 info
MPEG2/layer III
Bitrate: 8KBps
Frequency: 22KHz
#
Sigmund
Yes, the 8 kbps is wrong. The file was encoded with 64 kbps Variable Bit Rate. I guess ffmpeg doesn't know Variable Bit Rate.
As you can see in the first screenshot, you are right, it appears that Pmusic did tag the files. The numbering is still wrong because I haven't yet redone the tags with the new func_id3tagger.
In the second screenshot I've retagged the files after replacing func_id3tagger with the new one. As you can see, the numbers are now correct. Good work, and fast!
One thing that may cause problems in some cases is that there are no leading zeros. Some mp3 players or other apps may place 1 after 10. If you do add leading zeros, either go with three of them (0001, 0002, etc.) or perhaps a more sophisticated way would be to see how many files are to be tagged in the directory and adjust the number of leading zeroes to fit. But it looks like it will work the way it is.
I loaded the newly retagged book into one of my mp3 players and fired it up. As far as I could see, the stupid thing didn't use the tags. Where the heck is it getting the info it displays? I have several other, different, mp3 players I'll be trying out to see if they're the same way.
Edit: the second mp3 player I tried shows the first track as 01 - 79, Unknown artist, Unknown album, even though ffmpeg shows the metadata is different. What gives?
As you can see in the first screenshot, you are right, it appears that Pmusic did tag the files. The numbering is still wrong because I haven't yet redone the tags with the new func_id3tagger.
In the second screenshot I've retagged the files after replacing func_id3tagger with the new one. As you can see, the numbers are now correct. Good work, and fast!
One thing that may cause problems in some cases is that there are no leading zeros. Some mp3 players or other apps may place 1 after 10. If you do add leading zeros, either go with three of them (0001, 0002, etc.) or perhaps a more sophisticated way would be to see how many files are to be tagged in the directory and adjust the number of leading zeroes to fit. But it looks like it will work the way it is.
I loaded the newly retagged book into one of my mp3 players and fired it up. As far as I could see, the stupid thing didn't use the tags. Where the heck is it getting the info it displays? I have several other, different, mp3 players I'll be trying out to see if they're the same way.
Edit: the second mp3 player I tried shows the first track as 01 - 79, Unknown artist, Unknown album, even though ffmpeg shows the metadata is different. What gives?
- Attachments
-
- ffmpeg reads mp3 file tags.jpg
- (115.04 KiB) Downloaded 473 times
-
- Retag with new mp3tagger file.png
- (48.92 KiB) Downloaded 461 times
Flash
The attached tagger now supports id3 version 2.3, which is the most common id3 'standard'. I have checked here, and it works with id3info.
When it comes to leading zeros, I won't do anything before you encounter any trouble....
Sigmund
The attached tagger now supports id3 version 2.3, which is the most common id3 'standard'. I have checked here, and it works with id3info.
When it comes to leading zeros, I won't do anything before you encounter any trouble....
Sigmund
- Attachments
-
- func_id3tagger.gz
- (1.77 KiB) Downloaded 347 times
That did it! I replaced the old func_id3tagger in usr/local/Pmusic with the new one, tagged the mp3 files in an audio book directory the same way I did it a few posts above, and tried the newly tagged audio book in two different mp3 players from different manufacturers. The players both now show the artist and name of the book (as the album) while the file is playing. One of the mp3 players shows the track as 1 - 79 while the other shows it as 01 - 79. It might be that the second one is showing the file number rather than the metadata, who knows?
I won't know for sure until I've tagged several audio books and listened to them in different mp3 players, but it appears that for my purposes Pmusic's tagger works perfectly. .
I noticed that while it is tagging a bunch of mp3 files in a directory, Pmusic seems to open and close a console window for each file it tags. I seem to remember another Puppy app which did that at first, and a fix speeded it up noticeably. I can't remember what the app was. I think it had to do with ripping CDs and converting them to mp3.
I won't know for sure until I've tagged several audio books and listened to them in different mp3 players, but it appears that for my purposes Pmusic's tagger works perfectly. .
I noticed that while it is tagging a bunch of mp3 files in a directory, Pmusic seems to open and close a console window for each file it tags. I seem to remember another Puppy app which did that at first, and a fix speeded it up noticeably. I can't remember what the app was. I think it had to do with ripping CDs and converting them to mp3.
The reason for Pmusic masstagger is slow, is because ffmpeg (afaik) doesn't support tagging of existing file. - Only for the new output file. Earlier, when I tested this, it took ages waiting for ffmpeg to finish building new files with given meta-tags. Now, I let ffmpeg use the '-acodec copy' parameter which simply gives a straight copy (like cp) which is much faster compared to build a new stream.
Compared to tagging the existing file it will sure be slower. But I don't see the big deal. The only feature I find troublesome (with slower tag-reading) is the auto-loading of metatags when browsing/searching. This is now turned off by default.
On the other hand, Pmusic now supports tagging of more file-formats.
Sigmund
Compared to tagging the existing file it will sure be slower. But I don't see the big deal. The only feature I find troublesome (with slower tag-reading) is the auto-loading of metatags when browsing/searching. This is now turned off by default.
On the other hand, Pmusic now supports tagging of more file-formats.
Sigmund
Trouble is here.zigbert wrote:Flash
The attached tagger now supports id3 version 2.3, which is the most common id3 'standard'. I have checked here, and it works with id3info.
When it comes to leading zeros, I won't do anything before you encounter any trouble....
http://murga-linux.com/puppy/viewtopic. ... 920#612920
Sigmund
I bought a 4 GB SanDisk Sansa clip zip mp3 player. It is the first mp3 player (of at least 5 different kinds) I've tried that doesn't seem to play mp3 files in an audio book in the order they loaded. That's the good news. For the bad news, it apparently reads the id3 tags to determine the play order. It starts with number 10, then 20, then 100, then 200, etc. Oddly, it does play books with fewer than 100 files in the right order. I'm still investigating. Next I plan to load a book which has no id3 tags and see what the player does with that.
But the second time, coquillo freezed
I tried coquillo once, with the new puppies (Vivid 6.5)
Succes, with a picture from my computer. j'ai vu 'la vie en rose'
But the second time, coquillo freezed
What is a pity, is that nobody helps you.
Use pmusic and you are sure to get answers. What i am going to do..
Idiot users, they want to use applications included in the distro.
Coquillo in french means eggshell.. or bug (error)
Succes, with a picture from my computer. j'ai vu 'la vie en rose'
But the second time, coquillo freezed
What is a pity, is that nobody helps you.
Use pmusic and you are sure to get answers. What i am going to do..
Idiot users, they want to use applications included in the distro.
Coquillo in french means eggshell.. or bug (error)