Skip to main content
Topic: %__container% ? (Read 2523 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

%__container% ?

I would like to include the container format in FB's statusbar.  I realize I could just something like $ext(%_path%) to get the filename, but that might not correctly display the container in all instances.

%__container% ?

Reply #1
I don't honestly understand why everyone even thinks they need so many custom fields.  I know what format my music is in.  I know how to open Explorer if I need to look at the filesize.

__filesize, __format, __whatever

It all seems like a waste of programming effort.  I don't see any real reason for things like this.  I'm not Peter, of course, and it's entirely possible that Peter will add all these things, but I really don't see any valid reason to add a million custom fields.

I also don't see the point of the "__codec" field, which by the way, you should try.  It might fit your purposes.

%__container% ?

Reply #2
Quote
I also don't see the point of the "__codec" field, which by the way, you should try. It might fit your purposes.


Yeah, but sometimes there is a difference between the codec, and the container the codec is contained in. E.G. ogg, mp4, and matroska, can all contain different codecs.

Say what you will about containers, but personally I think they're a step in the right direction, especially for audio sources such as cd's.

%__container% ?

Reply #3
I think a unified container could be a good thing.  I don't really see the point of a million different containers which can each contain a million different codecs, though.

%__container% ?

Reply #4
Sorry, about the simple question.  But could anyome give me a brief explenation on what exactly a container format is and especially where it's advantages are in comparison of using a non contained format?

As far as I understand a container can contain one or more different file types and codecs.  Where exactly are it's advantages when used with only one filetype?

Have been wondering about this for a while now.

%__container% ?

Reply #5
Quote
I don't honestly understand why everyone even thinks they need so many custom fields.

It all seems like a waste of programming effort.  I don't see any real reason for things like this.  I'm not Peter, of course, and it's entirely possible that Peter will add all these things, but I really don't see any valid reason to add a million custom fields.

I don't honestly understand why there's such an opposition to the idea. Adding custom fields adds power to Tagz. If it's a meta-datum stored within my file or can be extracted, there's a chance that having the information could come in handy when dealing with (and thus possibly when playing) audio files. If it please the powers that be, make the custom field extensions a plug-in or something.

I can see no harm in increasing the number of custom fields. The code that interfaces them to Tagz is solid, as we've seen. There is no downfall to increasing the number, short of programmer effort and executable size. The programmer effort is key here. I don't care too much about executable size, nor do I think anyone really does, at least when dealing with a program on the scale of Foobar. Thus, make them extensible, and then programmers and users can customize these fields to their hearts' content, without affecting anyone else.

At very least, it would save us a lot of bitching.

%__container% ?

Reply #6
Quote
. . .

I think they would be a waste of time.  Look around.  There's plenty of requests for new fields.  There's a limit to how much Peter can do in any given time, and most requests are just frivolous.

. . .

I'm really not against adding all these extra custom fields.  I just think that 99% of them are a waste of time.  But in the end, it's up to Peter.  He can decide if they are worth the time or not


P.S.  Making them extensible isn't a bad idea, but I have a feeling it could lead to deadlock issues with database queries.  Of course, making them extensible isn't exactly trivial, either.

%__container% ?

Reply #7
Quote
I'm not Peter, of course, and it's entirely possible that Peter will add all these things, but I really don't see any valid reason to add a million custom fields.

That's not really up to Peter anyway. All that needs to be done is container format reporting by the respective input plugins.

For example, info->info_set("container", "ogg"); in the input plugin would make container info for this format available in formatting strings through %__container%, without involving any additional effort by Peter.
A riddle is a short sword attached to the next 2000 years.

%__container% ?

Reply #8
I think it'd be up to Peter to establish something like that.

 
SimplePortal 1.0.0 RC1 © 2008-2019