database : showing trackname whith no id3 given

[Chronon]

i do not have a good reason not to use a tag for the filename.
i have however some weak reason:
*its redunant. filename and id3tag for filename are the same in my libary. this argument only apllys to me, i confess.

Depending on your naming scheme this may be true about the majority of your metadata (album-artist, album, year, track number, track artist, etc.).  If this is a concern then why not just use a naming scheme that makes sense to you, strip all metadata from your files and use the file browser?

[motorbit]

yeah: all other tags are needed to run a metadata based libary smooth
however, tracknumber is redunant too if filenames are starting with the tracknumbers. most of my files indeed do not tracknumbers.

artist, album etc can not be save-guessed by metadata libarys.

but this does just not take place for the filename: there will be always a filename, there is no guessing.
thats why im sayed lots of time : there wuld be no noticable sideeffect for files that contain "correct" metadata, and there wuld be no error-potential because there wuld be no "guessing" for this specific sub-metadata.

you all are right if you say "rb is acting according to the id3 standard".
you are right if you say "you can fix it so it works with rb"

but im pretty sure im right too:
there wuld be no side effect by allowing users (and me ) this little freedom.

[evilnick]

There doesn't appear to be a compelling reason to change Rockbox to guess these values (Title and/or Track#) based on the filename for inclusion to the (tag) Database.

I do accept that in your specific case, it could make sense, but then again, if all your filenames are in a consistent format (Tracknumber - Title.Extension) then these could be used to generate the Track and Title tags anyway.

there wuld be no side effect by allowing users (and me) this little freedom.

The side effect of a developer's time taken to implement something that only you want would be seen as a bad thing.

Seriously, why not just update your library, and then this issue will go away?

[motorbit]

now, if its only that no one found the time to do it, maby ill find some and you let it into rb?
also, its not like i wuld not want to spend time on it to do it on my own, just i can not do it allone. maby someone wuld feel more comfortable helping me out putting the code in?

ot:
im curious: more metadata, wuld this not mean longer database buildup time?
with 48 gigs of slow flash memory, there is some reason in having few metadata

[Llorean]

There would also be the side effect of showing files in lists where the user doesn't want them.

You leave tags off "because it would be redundant." Other people leave tags off because they don't want those tags to exist - pretending like they do is an error.

If you want "filename" to be the last level of your filter, just edit tagnavi.

[soap]

Motorbit - you appear to have asked a perfectly reasonable question (roughly) 'Despite your solid points - why not add this teeny tiny feature?'

Llorean has touched upon one good reason - that the solution you propose for your personal edge case (for let's face it - it is an edge case) might cause conflicts for other edge cases.  While I think this is perfectly valid - I don't think it is the strongest argument against.

IMHO, the strongest argument against is general principle.  What I am about to say might sound weird coming from something as nerdy as an open source DAP firmware - but Rockbox can not afford to support every edge case - even though your assertion that this is likely a very small change is likely right.

PC media players (especially music ones) can pretty much pretend they have infinite resources.  The CPU and memory requirements for everything Rockbox can do are peanuts to a PC.  Power as well.
DAPs, though, are a teeny tiny resource-starved box.  Every single byte of code size is precious.  The more RAM taken by features the less left for the buffer and the more battery consumed by the hard drive.  Many of the devices Rockbox runs on have very small amounts of RAM.  (My 386 had more RAM than some of these players.)  Every single CPU cycle adds up to battery consumption as well as the big question if there are even free CPU cycles left.  (Have you ever tried to play Vorbis on the iPods with all five bands of the EQ active?)

This being taken into account I think it is quite reasonable not to expect your (admittedly) edge case to be considered for inclusion.  Especially considering you are (in effect) asking to use untagged files in the tag database.
Rockbox already accommodates your edge case in the (more general) WPS system.

[Llorean]

But a much larger set of edge cases (including sorting and filtering entirely untagged or *untaggable* files) could be handled by the format string variant, which could also solve his specific case.

[motorbit]

so, can you imagine any edge case where someone wuld prefear reading the null-info like "untagged" instead of the filename? i cant, because the one wuld still see the tag is missing because of the extension of the filename. printing untagged only makes it also more difficult to see witch file has a missing tag there.

to the ressources-hungryness:
a verry valid point. but rockbox must have some code for handling untagged files already.
logic wise, i think i shuld be something like:

if $id3-filename ="null" print "untagged"

now, wuld

if $id3-filename ="null" print "filename"

require so much more ressources?

its just an assumption, but i guess it wuld require changing only one line of code, not adding a new module to the kernel or dozends of lines for another compute-intensive calculation running in background all the time.

[Llorean]

Please, make use of the forum's spell checker. It's getting really irritating reading words like "wuld" and "prefear" that don't even exist. I know you've mentioned limited English, but you don't have to make up spellings as you go along.

If a file is untagged, why should it be assumed that it's *not* intentional? It's entirely possible for you to tag your files, but you're suggesting that "no title tag" shouldn't mean "no title" when for some people it does.

I have several audiobooks that don't have separate title tags because I've just titled the Album as the book name, and the individual files are simply disk breaks. The "track" number represents the disk number for me, and if I were in the database I wouldn't expect nor want to see filenames as the filenames are redundant to the information I need.

Again I ask - why can't you just use the existing filename support in the database for your personal edge case? It sounds like you only want to use filenames and not metadata for the track name, which from my understanding is actually supported, it's just fallback that isn't.

[motorbit]

right. these numbers probably would scare you.

anyway, arguments are exchanged, i don't think there will come some new ones along. it seems everyone  to have come to a fixed opinion.
thanks for your attention.

[AlexP]

Personally I would want to see that things were untagged so that I could fix my tags.

[motorbit]

this was discussed already: id3 trag tag don´t have an extension.

[evilnick]

I think that this topic has run it's course.

If you don't want to add the Title tag then don't use the database. If you want to use the database then tag your files.