Skip to main content
Topic: m-TAGS component (foo_tags) (Read 81949 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: m-TAGS component (foo_tags)

Reply #275
@luigimercurio

Got a suggestion for a possible future release.
[...]

It could be useful, but definitely far from a priority. Unless otherwise notified, I assume that for most people just excluding *.cue from the incoming files is sufficient.
You misunderstood me :)  I'm not interested in hiding just cue files, since the cue filter component already does that.
I meant m-TAGS to hide the files it is referring to itself in .tags files, which is not limited to just cue files, so basically a similar functionality but not limited to cue files.

I've run into a situation that may lead to an m-TAG file not reflecting the actual tag values of the media files.

Due to our setup, media files may get their tag content updated from other sources.
When this occurs, normally the changed information would be read into FB2K via context menu > Tagging > "Reload info from file(s)"

[...]

m-TAGS is NOT made to reflect tags in media files. If that was the case, you would not need m-TAGS at all. m-TAGS is made to read/write tags without touching the media files. Your system should update the m-TAGS files as opposed to the media files, if that is possible (I do not know how your setup works).

If your tags are dinamically updated, though, then m-TAGS should reflect the dynamic changes, provided you do not have a fixed value for the dynamically changing tag in the m-TAG file (in other words, m-TAG tags have precedence).
I am aware that it is not meant to dynamically reflect tag values. But the thing is. there are situations where media files can get their tag information updated from sources that do not understand how to use m-TAG or are simply completely unaware that such functionality exists.

Also I was not looking for dynamic functionality. But in the case of manually and explicitly calling a function to reread tag information this action should IMO ripple through to the lowest possible source in the chain (Foobar > tagging layer > media file) when using Tagging > "Reload info from file(s)".  Precisely for the same reason as explained above where information can get changed by other sources that are not able to use m-TAGS or are completely oblivious to its existence (since it only exists as FB2K component).

I'm not asking for m-TAGS to automatically go and re read the tags every time a file is referenced. But only when explicitly indicated by using the FB2K provided command to do so.

And as I explained, since FB2K is not the only program capable of touching media files there are just situations in my case where it cannot be avoided that information is changed in other sources.

Also, since you already hinted at it yourself, it does pick up dynamic data where tag info gets changed by external sources (for tags that are not present in the .tags file itself (like artist/title in a stream) which works perfectly.

What I am suggesting would be nothing other than that same functionality applied when explicitly instructing FB2K to go out and look for updated/added tags. Again, stressing that I'm not looking for a dynamic option as exists for streams in this situation.

PS. Also, with all due respect, even the FB2K developers realized that the possibility for tags getting added/changed in sources than FB2K itself exists, otherwise the command "Reload info from file(s)" would not have been present in the first place.

Re: m-TAGS component (foo_tags)

Reply #276
This is great plugin but there are 2 flaws I noticed:
1. you can attach cue sheet to file but you can't see separate tracks in playlist
2. when you have more than 1 album tags written in one file you can attach just one album cover for all albums

I guess with "attach cue sheet to file" you refer to embedded cue sheets. m-TAGS will reflect embedded cue sheets, but to edit them you need to load the media file in fb2k. As far as m-TAGS is concerned, a cuesheet entry is just a seekpoint.

As for 2., that is true and intentional. An m-TAGS file is treated by fb2k as a single multitrack media file. As a result, only one set of covers is applied to the whole file. Please remember that m-TAGS files are not playlists, are not treated as such by fb2k, and should not be used as such.
It would be truly awesome if m-TAGS file could be playlist with its own tags!

Re: m-TAGS component (foo_tags)

Reply #277
This is great plugin but there are 2 flaws I noticed:
1. you can attach cue sheet to file but you can't see separate tracks in playlist
2. when you have more than 1 album tags written in one file you can attach just one album cover for all albums

I guess with "attach cue sheet to file" you refer to embedded cue sheets. m-TAGS will reflect embedded cue sheets, but to edit them you need to load the media file in fb2k. As far as m-TAGS is concerned, a cuesheet entry is just a seekpoint.

As for 2., that is true and intentional. An m-TAGS file is treated by fb2k as a single multitrack media file. As a result, only one set of covers is applied to the whole file. Please remember that m-TAGS files are not playlists, are not treated as such by fb2k, and should not be used as such.
It would be truly awesome if m-TAGS file could be playlist with its own tags!

Well, a playlist is not a media file and vice-versa. The two things are different and, rightfully enough, differently treated by fb2k.

I do use my own playlist mechanism in conjunction with m-TAGS. It is nothing else than a slightly more flexible m3u-like playlist format (the "added-values" being that you can reference folders, subtracks, and other playlists within the playlist). But I never published this addon.

Re: m-TAGS component (foo_tags)

Reply #278
@luigimercurio

Got a suggestion for a possible future release.
[...]

It could be useful, but definitely far from a priority. Unless otherwise notified, I assume that for most people just excluding *.cue from the incoming files is sufficient.
You misunderstood me :)  I'm not interested in hiding just cue files, since the cue filter component already does that.
I meant m-TAGS to hide the files it is referring to itself in .tags files, which is not limited to just cue files, so basically a similar functionality but not limited to cue files.

I've run into a situation that may lead to an m-TAG file not reflecting the actual tag values of the media files.

Due to our setup, media files may get their tag content updated from other sources.
When this occurs, normally the changed information would be read into FB2K via context menu > Tagging > "Reload info from file(s)"

[...]

m-TAGS is NOT made to reflect tags in media files. If that was the case, you would not need m-TAGS at all. m-TAGS is made to read/write tags without touching the media files. Your system should update the m-TAGS files as opposed to the media files, if that is possible (I do not know how your setup works).

If your tags are dinamically updated, though, then m-TAGS should reflect the dynamic changes, provided you do not have a fixed value for the dynamically changing tag in the m-TAG file (in other words, m-TAG tags have precedence).
I am aware that it is not meant to dynamically reflect tag values. But the thing is. there are situations where media files can get their tag information updated from sources that do not understand how to use m-TAG or are simply completely unaware that such functionality exists.

Also I was not looking for dynamic functionality. But in the case of manually and explicitly calling a function to reread tag information this action should IMO ripple through to the lowest possible source in the chain (Foobar > tagging layer > media file) when using Tagging > "Reload info from file(s)".  Precisely for the same reason as explained above where information can get changed by other sources that are not able to use m-TAGS or are completely oblivious to its existence (since it only exists as FB2K component).

I'm not asking for m-TAGS to automatically go and re read the tags every time a file is referenced. But only when explicitly indicated by using the FB2K provided command to do so.

And as I explained, since FB2K is not the only program capable of touching media files there are just situations in my case where it cannot be avoided that information is changed in other sources.

Also, since you already hinted at it yourself, it does pick up dynamic data where tag info gets changed by external sources (for tags that are not present in the .tags file itself (like artist/title in a stream) which works perfectly.

What I am suggesting would be nothing other than that same functionality applied when explicitly instructing FB2K to go out and look for updated/added tags. Again, stressing that I'm not looking for a dynamic option as exists for streams in this situation.

PS. Also, with all due respect, even the FB2K developers realized that the possibility for tags getting added/changed in sources than FB2K itself exists, otherwise the command "Reload info from file(s)" would not have been present in the first place.


Your point no. 1 is well taken. But I am not sufficiently expert of playlist handling to provide that functionality without spending some time studying how fb2k would allow me to hide files. Maybe the developer of the cue-hiding add-on can illuminate me?

As for point no. 2, the ramifications are more complex. To start with, what you ask requires another menu option ("reload info from files" just reloads the m-TAGS file, of course, and rightly so). What you really want is m-TAGS to be able to "revert" to the referenced media's tags without having to explicitly recreate the m-TAGS file.

Also, m-TAGS was created in order NOT to modify media files, and (philosophically, if you want) assumes that media files are immutable. I (quite reluctantly) added the much requested option to write back the m-TAGS tags to the media files because I understand that there are cases in which this is desirable, particularly when copying files to devices which do not have fb2k.

However, unlike the option to rewrite the media file tags, the option to re-read the tags would open a can of worms. What if you want to re-read a subset of tags, but leave others unchanged in m-TAGS??? Now you need a "selection mask" of some sort. So, what's supposed to make something a little simpler, could become more cumbersome than expected.




Re: m-TAGS component (foo_tags)

Reply #279
[...]

Your point no. 1 is well taken. But I am not sufficiently expert of playlist handling to provide that functionality without spending some time studying how fb2k would allow me to hide files. Maybe the developer of the cue-hiding add-on can illuminate me?

As for point no. 2, the ramifications are more complex. To start with, what you ask requires another menu option ("reload info from files" just reloads the m-TAGS file, of course, and rightly so). What you really want is m-TAGS to be able to "revert" to the referenced media's tags without having to explicitly recreate the m-TAGS file.

Also, m-TAGS was created in order NOT to modify media files, and (philosophically, if you want) assumes that media files are immutable. I (quite reluctantly) added the much requested option to write back the m-TAGS tags to the media files because I understand that there are cases in which this is desirable, particularly when copying files to devices which do not have fb2k.

However, unlike the option to rewrite the media file tags, the option to re-read the tags would open a can of worms. What if you want to re-read a subset of tags, but leave others unchanged in m-TAGS??? Now you need a "selection mask" of some sort. So, what's supposed to make something a little simpler, could become more cumbersome than expected.
I realize that this could lead to all kinds of problems.  And I can only speak for myself of course but personally I would already be glad if it only would collect information from media file tags which are not already present in the m-TAGs file itself, so basically ignoring any media tags already existing in a tags file, even if their values might differ. The tags file is after all supposed to be leading here.

But I also can imagine that once that door is open, wishes might arise among other users for a somewhat more controlled form. In its simplest form this could be the use of a set of user defined tags to consider protected from updating. And anything that is not included in that set is fair game as far as updating is concerned. Otoh, it could be left totally up to the user with a dialog akin to how Picard displays original value and proposed new value.

But as I said, personally I'd already be glad to have it only read in values for tags not yet present in the m-TAGs file. Even this would already allow some form of user control because if a user actually wanted to have existing m-TAG tags updated, all he or she would have to do in that case is right-click, select properties and clear the value before reading in any new values. Thus the responsibility for any changes to existing values lies totally with the end-user.

Re: m-TAGS component (foo_tags)

Reply #280
Hello, I'm trying to play some tracks and got this error
(The logs below have been narrowed down to the tracks that returns this error.)

Code: [Select]
Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 126

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 127

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 157

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 159

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 161

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 173

I've also attached the verbose log in the attachment below.
In the properties dialog, I also noticed that these tracks have empty @REFERENCE_FILES column and -1 for  the @REFERENCE_INDEX. The @ returns proper file path though. Basically mTAGS read the tags just fine (and probably the files as well) but refuses to play them (in addition that I also can't convert these files as well)

I believe this is not caused by filename as even though the track's tags are in Japanese, the whole directory & file naming is completely romanized and free from any unicode/forbidden file name strings. The files are also intact and not corrupted at all when played directly.
I compared the faulty playback with another tracks but there's not much of any difference, even in the .tags file, apart from one thing: these tracks had the longest file path among any other working tracks. Is that the cause?

Re: m-TAGS component (foo_tags)

Reply #281
Hello, I'm trying to play some tracks and got this error
(The logs below have been narrowed down to the tracks that returns this error.)

Code: [Select]
Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 126

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 127

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 157

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 159

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 161

Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\Hidamari Sketch.tags" / index: 173

I've also attached the verbose log in the attachment below.
In the properties dialog, I also noticed that these tracks have empty @REFERENCE_FILES column and -1 for  the @REFERENCE_INDEX. The @ returns proper file path though. Basically mTAGS read the tags just fine (and probably the files as well) but refuses to play them (in addition that I also can't convert these files as well)

I believe this is not caused by filename as even though the track's tags are in Japanese, the whole directory & file naming is completely romanized and free from any unicode/forbidden file name strings. The files are also intact and not corrupted at all when played directly.
I compared the faulty playback with another tracks but there's not much of any difference, even in the .tags file, apart from one thing: these tracks had the longest file path among any other working tracks. Is that the cause?

Your diagnose is most likely correct. Windows has a limitation in the length of a file path, and it is a well-known source of all sorts of problems. The hint in this case is the following extract from the log file:

m-TAGS:: archive ref_file: file://F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\..\..\..\Hidamari Sketch, Collective\Hidamari Sketch x Hoshimittsu OP - Dekiru Kanatte Hoshimittsu [Kana Asumi, Kaori Mizuhashi, Yuuko Gotou, Ryouko Shintani]\03 - Dekiru Kanatte Hoshimittsu (off vocal).flac
m-TAGS:: Canonical path: file://F:\Multimedia\Music\#Tracklisting\2016-04-04\Anime releases\..\..\..\Hidamari Sketch, Collective\Hidamari Sketch x Hoshimittsu OP - Dekiru Kanatte Hoshimittsu [Kana Asumi, Kaori Mizuhashi, Yuuko Gotou, Ryouko Shintani]\03 - Dekiru Kanatte Hoshimittsu (off vocal).flac

The Canonical path should be "file://F:\Multimedia\Music\Hidamari Sketch, Collective\Hidamari Sketch x Hoshimittsu OP - Dekiru Kanatte Hoshimittsu [Kana Asumi, Kaori Mizuhashi, Yuuko Gotou, Ryouko Shintani]\03 - Dekiru Kanatte Hoshimittsu (off vocal).flac"

That is, the "relative" portion of the path should have been resolved and the path minimized. It is an internal fb2k routine which does this (filesystem::g_get_canonical_path(), if you are familiar with the SDK). This routine obviously fails for the reported files, and I believe it fails exactly because the paths are too long for windows to handle. The default behaviour of the routine in case of failure is to return the path "as-is". But this then makes the decoding process fail.

Another reason could be that the files simply do not exist or are not where they should be according to the locator, but I have to assume that you did verify that they do exist.

Re: m-TAGS component (foo_tags)

Reply #282
[...]

Your point no. 1 is well taken. But I am not sufficiently expert of playlist handling to provide that functionality without spending some time studying how fb2k would allow me to hide files. Maybe the developer of the cue-hiding add-on can illuminate me?

As for point no. 2, the ramifications are more complex. To start with, what you ask requires another menu option ("reload info from files" just reloads the m-TAGS file, of course, and rightly so). What you really want is m-TAGS to be able to "revert" to the referenced media's tags without having to explicitly recreate the m-TAGS file.

Also, m-TAGS was created in order NOT to modify media files, and (philosophically, if you want) assumes that media files are immutable. I (quite reluctantly) added the much requested option to write back the m-TAGS tags to the media files because I understand that there are cases in which this is desirable, particularly when copying files to devices which do not have fb2k.

However, unlike the option to rewrite the media file tags, the option to re-read the tags would open a can of worms. What if you want to re-read a subset of tags, but leave others unchanged in m-TAGS??? Now you need a "selection mask" of some sort. So, what's supposed to make something a little simpler, could become more cumbersome than expected.
I realize that this could lead to all kinds of problems.  And I can only speak for myself of course but personally I would already be glad if it only would collect information from media file tags which are not already present in the m-TAGs file itself, so basically ignoring any media tags already existing in a tags file, even if their values might differ. The tags file is after all supposed to be leading here.

But I also can imagine that once that door is open, wishes might arise among other users for a somewhat more controlled form. In its simplest form this could be the use of a set of user defined tags to consider protected from updating. And anything that is not included in that set is fair game as far as updating is concerned. Otoh, it could be left totally up to the user with a dialog akin to how Picard displays original value and proposed new value.

But as I said, personally I'd already be glad to have it only read in values for tags not yet present in the m-TAGs file. Even this would already allow some form of user control because if a user actually wanted to have existing m-TAG tags updated, all he or she would have to do in that case is right-click, select properties and clear the value before reading in any new values. Thus the responsibility for any changes to existing values lies totally with the end-user.

This would not work, because it would also reload back tags that are present in the media file, but which I do NOT want to be present in the m-TAGS files.

Re: m-TAGS component (foo_tags)

Reply #283
Is it possible to save an m3u8 playlist with the corresponding source media instead of the tag files?

Also, after I rip a CD, select it and choose Create m-TAGS from the Tagging context menu; I'm prompted to save but the dialog box sits there and doesn't create the m-TAGS files.

Re: m-TAGS component (foo_tags)

Reply #284
nope, it does not make m3u8 files,

If the dialog box just sits there and clicking on Save doesn't do anything then you've not yet typed a name to save the file with...


Re: m-TAGS component (foo_tags)

Reply #285
nope, it does not make m3u8 files,
To clarify. I created an FPL playlist and I want to save it as m3u8 with the source files.

If the dialog box just sits there and clicking on Save doesn't do anything then you've not yet typed a name to save the file with...
I'm not typing anything in the name. Do I have to create the whole path and filename?

Re: m-TAGS component (foo_tags)

Reply #286
is there any way to make foobar read the cover art in the original mp3 file, or a way to write the cover art into the mtag file?

it's problematic for me becasue all my songs in the library are singles, every one of them has its own different cover art.

Re: m-TAGS component (foo_tags)

Reply #287
nope, it does not make m3u8 files,
To clarify. I created an FPL playlist and I want to save it as m3u8 with the source files.
Oh than I misunderstood, my bad. You can save a playlist either as FPL, M3U or M3U8 by using the filetype dropdown in the "File > Save Playlist..." dialog. You need to provide the name yourself and navigate to the desired location where to save it...
But I've no idea if the resulting files are saved in the  way you expect with regards to formatting.

If the dialog box just sits there and clicking on Save doesn't do anything then you've not yet typed a name to save the file with...
I'm not typing anything in the name. Do I have to create the whole path and filename?
Similar to saving playlists, when using the Tagging context menu option for m-TAGS, you must provide a filename yourself (you do not need to type the extension as it will be automatically added). And here too, if you use the dialog to navigate to where you want it saved you do not need to provide the full path

Re: m-TAGS component (foo_tags)

Reply #288
is there any way to make foobar read the cover art in the original mp3 file, or a way to write the cover art into the mtag file?

it's problematic for me becasue all my songs in the library are singles, every one of them has its own different cover art.
Yes, go to File > Preferences > Advanced > Tagging > m-TAGS > m-TAGS Creator and put a checkmark in the box for "Create a separate m-TAGS file each source file". You may also need to put a checkmark  in the box for "Keep source files extension in non-folder wide m-TAGS file names". The latter is to get around situations where files with the same name, but with different media extensions would end up in the same tags file otherwise.

 

Re: m-TAGS component (foo_tags)

Reply #289
nope, it does not make m3u8 files,
To clarify. I created an FPL playlist and I want to save it as m3u8 with the source files.
Oh than I misunderstood, my bad. You can save a playlist either as FPL, M3U or M3U8 by using the filetype dropdown in the "File > Save Playlist..." dialog. You need to provide the name yourself and navigate to the desired location where to save it...
But I've no idea if the resulting files are saved in the  way you expect with regards to formatting.
I know the steps to save a playlist. I want save a playlist with the paths of the mp3 files. Right now if I save a playlist of tag files, it saves the path of the tags; not the mp3s.

If the dialog box just sits there and clicking on Save doesn't do anything then you've not yet typed a name to save the file with...
I'm not typing anything in the name. Do I have to create the whole path and filename?
Similar to saving playlists, when using the Tagging context menu option for m-TAGS, you must provide a filename yourself (you do not need to type the extension as it will be automatically added). And here too, if you use the dialog to navigate to where you want it saved you do not need to provide the full path
This seems to work completely differently than selecting File > m-TAGS > Create m-TAGS (in separate folder) which does not require providing a filename. I figured out though if I rescan the entire path, the m-TAGS for the new files will be created. The context menu option seems useless in this case. Perhaps luigimercurio can describe his intent for the function.

Re: m-TAGS component (foo_tags)

Reply #290
is there any way to make foobar read the cover art in the original mp3 file, or a way to write the cover art into the mtag file?

it's problematic for me becasue all my songs in the library are singles, every one of them has its own different cover art.
Yes, go to File > Preferences > Advanced > Tagging > m-TAGS > m-TAGS Creator and put a checkmark in the box for "Create a separate m-TAGS file each source file". You may also need to put a checkmark  in the box for "Keep source files extension in non-folder wide m-TAGS file names". The latter is to get around situations where files with the same name, but with different media extensions would end up in the same tags file otherwise.

this kinda defeats the original purpose, and backwards the technology to when music files cant hold song meta info

Re: m-TAGS component (foo_tags)

Reply #291
is there any way to make foobar read the cover art in the original mp3 file, or a way to write the cover art into the mtag file?

it's problematic for me becasue all my songs in the library are singles, every one of them has its own different cover art.
Yes, go to File > Preferences > Advanced > Tagging > m-TAGS > m-TAGS Creator and put a checkmark in the box for "Create a separate m-TAGS file each source file". You may also need to put a checkmark  in the box for "Keep source files extension in non-folder wide m-TAGS file names". The latter is to get around situations where files with the same name, but with different media extensions would end up in the same tags file otherwise.

this kinda defeats the original purpose, and backwards the technology to when music files cant hold song meta info
Backwards? Then why use m-TAGS in the first place?

It's sole purpose is to do exactly that, keeping the meta info separate from the music files. And there's nothing backwards about that, considering there's still media formats with poor or non-existing support for media info. Backwards is Win10 still not being able to read and display ID3v2.4 in Explorer...

Re: m-TAGS component (foo_tags)

Reply #292
is there any way to make foobar read the cover art in the original mp3 file, or a way to write the cover art into the mtag file?

it's problematic for me becasue all my songs in the library are singles, every one of them has its own different cover art.
Yes, go to File > Preferences > Advanced > Tagging > m-TAGS > m-TAGS Creator and put a checkmark in the box for "Create a separate m-TAGS file each source file". You may also need to put a checkmark  in the box for "Keep source files extension in non-folder wide m-TAGS file names". The latter is to get around situations where files with the same name, but with different media extensions would end up in the same tags file otherwise.

this kinda defeats the original purpose, and backwards the technology to when music files cant hold song meta info
Backwards? Then why use m-TAGS in the first place?

It's sole purpose is to do exactly that, keeping the meta info separate from the music files. And there's nothing backwards about that, considering there's still media formats with poor or non-existing support for media info. Backwards is Win10 still not being able to read and display ID3v2.4 in Explorer...

i use it to store all the meta info of my library in one single or several file for easier management/update/sync,

Re: m-TAGS component (foo_tags)

Reply #293
Is it possible to save an m3u8 playlist with the corresponding source media instead of the tag files?

luigimercurio

You mentioned an unreleased playlist tool in another reply. Would that tool allow me to create an m3u8 playlist of the source files that are referenced in the tag files? I need to export my playlist to use on another device.

Re: m-TAGS component (foo_tags)

Reply #294
I'm seeing a bug where m-Tags has trouble with some files that have non-alpha characters in the filename. If you look at the attached tag file. I was able to fix tracks 7 and 10 by removing [Edited Version] from the mp3's tag and regenerating the tag file. For some reason this did not fix track 6 which only has a period or track 12 which has parens. Removing the period and parens did not fix these tracks.

The source mp3 plays fine but the tag reference is missing duration and results in a playback error.
Code: [Select]
Decoding failure at 0:00.000 (Unsupported format or corrupted file):
"C:\Users\Cristov\Music\m-TAGS\Yo-Yo Ma & The Silk Road Ensemble\Silk Road Journeys - When Strangers Meet\!.tags" / index: 6

Re: m-TAGS component (foo_tags)

Reply #295
Just as a test, I tried ripping these as FLAC files and m-TAGS has the same issue with these as well.

Re: m-TAGS component (foo_tags)

Reply #296
Hey luigi. This is probably wishful thinking, but I've noticed other components (e.g. PSF Decoder) fails to recognize tags loaded in from m-TAGS. I was wondering if there is any way you can possibly update your component to have other components recognize them?

In fact, if that's not possible, I'm thinking Peter should really try to implement a "component precedence" system or something, which would be configurable (to some extent at least) by the user. That'd be really neat. Or would that not necessarily solve this problem?

Re: m-TAGS component (foo_tags)

Reply #297
Hey luigi. This is probably wishful thinking, but I've noticed other components (e.g. PSF Decoder) fails to recognize tags loaded in from m-TAGS. I was wondering if there is any way you can possibly update your component to have other components recognize them?

In fact, if that's not possible, I'm thinking Peter should really try to implement a "component precedence" system or something, which would be configurable (to some extent at least) by the user. That'd be really neat. Or would that not necessarily solve this problem?

Nisto, I am not sure about the nature of your problem, and how it manifests itself. There is no difference, as far as internal behaviour of fb2k, between m-TAGS and any other media format (keeping in mind that fb2k sees m-TAGS as a FORMAT and not a PLAYLIST).

Can you send me a log, or put here an extract?

Re: m-TAGS component (foo_tags)

Reply #298
Apologies for the unclear question. The problem is particularly with functional tags. PSF Decoder, for example, supports several such tags (_usefifofull, volume, fade, length). However, when using them in m-TAGS files, the gain doesn't change when using the "volume" tag, and fade-outs aren't applied when using the "fade" tag, etc. But I've been thinking.. maybe it parses those tags differently? They are specified exactly like other ("non-functional") tags in the PSF format, but when loading *.psf files (containing functional tags) directly, those tags don't appear in the (Selection) Properties element/window like artist, title and other common tags do. So if I'm correct, I guess there's not much that can be done, huh? :/

I'm not finding anything that would be of any help in the fb2k logs. But you could test it out yourself. You can find PSF files on lots of places, and the PSF Decoder component is in the official repository. Can you make any sense of this?

Re: m-TAGS component (foo_tags)

Reply #299
My PSF decoders ignore the volume tag and read and write ReplayGain tags instead.

The length and fade fields are also in human readable timestamp format, hh:mm:ss.ms.

And you can't expect an external database to override them, as they're read directly from the files every time you play them.

 
SimplePortal 1.0.0 RC1 © 2008-2019