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: Some feature requests :) (Read 4430 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Some feature requests :)

A few things I think might be nifty in foobar:

- Some more fields for display strings..
%__filesize%: returns the file size in bytes
%__path_volumelabel%: returns the volume label for the drive a song is on (for cataloging CD collections)

- Some database features..
Some qualifiers on the "Remove dead entries" function would be nice... so that removing dead entries would leave entries for songs on CD's that aren't inserted right now. Granted, this can be done by searching the database by path, adding all the hard-drive entries, and then killing dead entries on that list, so it's probably not really necessary :P

- Replaygain manual edit functions in the mass tagger
..so that one can remove just the album replaygain fields from some selection, for example. That might be useful for scanning a CD that contains both albums and free-floating songs -- if one wanted to scan the thing overnight ('cause it takes a while if your computer's slowish like mine) one could scan the whole thing as 'album by album field' and remove the entries for album gain / album peak from the freefloaters in the morning. (The alternative would be to scan the albums [alba?] as one selection by album tags, and the freefloaters as another selection of per-track gains only, except that [most] cd drives only have one laser, causing <seekseek><seekseek><seekseek> to happen for the duration of the two scans, which is annoying and probably stressful... A queuing option for the replaygain scanner would also solve this; one could tell it to wait until the first job's done before scanning the freefloaters).

- A plugin for backwards-compatibility?
Could a plugin be written that runs the plugins made with older SDK's? I'm not a programmer so I assume there are reasons for not making newer foobars backwards-compatible with older plugins, but it seems illogical that 'done' plugins should have to be recompiled & rereleased so often... And many of them aren't; I'm still waiting for a 0.6 version of the Speex input plugin to come out. Also, some plugins seem to be beta-specific as well; they'll run on 0.6 beta 5 but not on 0.6 beta 14, which I think is just nuts (...though there must be a reason for it.. right? Right? :)

- Less wimpy replaygain
When replaygain encounters a problem, it stops (see my post in the 0.6 public test thread, Apr 18 2003 - 07:11 PM GMT-8:00). I think it should keep going on to the next file, for the above reason that I often leave it unattended 'cause it's a time-consuming process.

- Make colouring not interrupted by tabs
Tab characters seem to reset colours back to defaults in the display strings, so my complicated colouring function has to be repeated after every set of tabs... Is this an intentional behaviour or would nobody mind if it were changed (so that a colour specification lasts until the next colour specification, or if there were colour start & end delimiters)?

ok I think I'm done :)
Death to graphic smilies! :P
(Stupid MSN.. I'll never forgive them for that... it took me 2 years to realise that (Y) was really a thumbs-up -- all this time I thought I was being mooned! --Or eaten by Pacman . . . )

Some feature requests :)

Reply #1
Quote
- Some more fields for display strings..
%__filesize%: returns the file size in bytes

You can calculate this from the length and bitrate of the file.

Quote
%__path_volumelabel%: returns the volume label for the drive a song is on (for cataloging CD collections)


I think this is unnecessary really.  You can setup code to insert the volume label (from a set of variables you define) for a drive according to what the returned path of the file is.

Quote
- A plugin for backwards-compatibility?
Could a plugin be written that runs the plugins made with older SDK's? I'm not a programmer so I assume there are reasons for not making newer foobars backwards-compatible with older plugins, but it seems illogical that 'done' plugins should have to be recompiled & rereleased so often... And many of them aren't; I'm still waiting for a 0.6 version of the Speex input plugin to come out. Also, some plugins seem to be beta-specific as well; they'll run on 0.6 beta 5 but not on 0.6 beta 14, which I think is just nuts (...though there must be a reason for it.. right? Right?


This is a bad idea.  Something like this would not only end up possibly limiting the functionality of certain plugins, but it would also encourage a certain design mentality which is undesireable.  Furthermore, it's basically a hackish solution, and in the long run would cause more problems then it would solve.


Some feature requests :)

Reply #3
Quote
Quote
%__filesize%: returns the file size in bytes

You can calculate this from the length and bitrate of the file.

not exactly.. I need (or rather, would much prefer) the actual filesize -- doing this fails to take into account padding, tags, et cetera. (for example, one for one file I tried this on $div($mul(%__bitrate%,%_length_seconds%,1000),8) returns 3 632 000, or 3 719 168 if I change that 1000 to 1024 (I never know which to use :P), neither of which is the correct value for my 3 627 385-byte file.. while the difference may seem trivial, it's not when you're using the byte count as one method of dupe-checking (it's not my only method, don't worry :)

Now, I suppose one could try to factor in the tag by doing something like
Code: [Select]
$add($len([%artist%][%title%][%performer%]
[%composer%][%date%][%tracknumber%][%comment%][%album%]),46,15,14)


but it's those last few values (tag padding & such, gotten with a hex editor) that change all over the place from file to file, depending on whether ID3v2, APE2, or ID3v1 are present in varying combinations and (...) Don't you think that warrants a %__filesize%?

Quote
Quote
%__path_volumelabel%: returns the volume label for the drive a song is on (for cataloging CD collections)


I think this is unnecessary really.  You can setup code to insert the volume label (from a set of variables you define) for a drive according to what the returned path of the file is.


nonono, see, I want to be able to distinguish between songs on MP3Vol31 and MP3Vol32, both of which are CD's that would be in the W:\ drive (at different times of course)...so going by driveletter/path wouldn't work at all... I suppose I could make my CD's so that all files contained therein are in a subdirectory by the volume name but I don't really feel like it, plus I can't update my existing CD-R's because they're completely full (no room for multisession) and finalized.

Also, I did consider adding tag values (so that I could use %volumelabel% or something), but the read-only problem crops up again, and I also I decided that it would be an inconsiderate thing to do (since those tags would only apply to me, and would mean nothing to anyone to whom I send the file) and I it really peeves me when I get other people's irrelevant comment fields in files I download ;)

Quote
[making a backwards-compatible plugin reader thingie] is a bad idea.

yea ok, just thought I'd check :)

Quote
foo_speex for 0.6: http://www.saunalahti.fi/cse/foobar2000/fo...o_speex_0.6.exe

Thanks dude :)
Death to graphic smilies! :P
(Stupid MSN.. I'll never forgive them for that... it took me 2 years to realise that (Y) was really a thumbs-up -- all this time I thought I was being mooned! --Or eaten by Pacman . . . )

Some feature requests :)

Reply #4
Oh yea, one more minor little feature-request thing:

How about sorting the lists in the Syntax Reference help thingie somehow? There doesn't seem to be any real order to them, alphabetical, function-wise, or otherwise...

also, it would be nice if foobar could have a plain-text config file, and not crash if I edit the thing manually ;)
Death to graphic smilies! :P
(Stupid MSN.. I'll never forgive them for that... it took me 2 years to realise that (Y) was really a thumbs-up -- all this time I thought I was being mooned! --Or eaten by Pacman . . . )

Some feature requests :)

Reply #5
Then use your brain when editing the config. All fields are formatted:

int name_length
char name[name_length]
int data_length
void data[data_length bytes]

Integer lengths are little-endian. I have no idea how many fields outside of a single value are affected if you should decide to change the length of the field. (Other than that field's length value.)

The best advice: Look, but don't touch.

Some feature requests :)

Reply #6

> dibrom said

>> thetrivialstuff said
>> Some more fields for display strings::
>>  %__filesize%: returns the file size in bytes

> You can calculate this from the length and bitrate of the file.


this was discussed already, and you cannot calculate file size
based on the bitrate of the file as not all files have a bitrate (or,
to be consistant with VLSI: "not all files have easily calculatable
bitrate" and bothering to actualy calculate the bitrate would be
wasting resources)..

Please review the same request at:
>>  http://www.hydrogenaudio.org/show.php/act/.../ST/f/27/t/8313


Some feature requests :)

Reply #7
What good is %filesize%?

Some feature requests :)

Reply #8

> Curi0us_George asked:
> What good is %filesize%?


its one of those things that would be nice to have.

following that logic: what good is bitrate or song length or
song comment  or song album? If I like a song, I dont care
what album its from. Do I care for bitrate? Different
encoders have different bitrate for sweet points
(mp2 vs mp3 vs ogg... xing vs lame) so bitrate is useless too.
Similiarly song comments are useless as its usually some kid
proclaiming how leet his cd ripping skills are within some
unheard of irc piracy group.


things I want:
-> File Size
-> what plugin used to play a file
-> technical info from the file
--->  is it joint stereo? or stereo?
All I get to know is how many channels
--->  is it mp3 or mp3pro
--->  does the file contain internal crc data?
either mp3 crc data or the mp3 vaccinator by morgoth.
--->  for modules: what version of the format the file is in?
ie: newer Impulse Tracker files have compressed samples


Some feature requests :)

Reply #9
As long as we're going to store all possible information about the file, we might as well just store the whole file in the database.

Some feature requests :)

Reply #10


well, if this is the true reason its not there, and not just
an oversight, then I am happy.


However I see new tags added (%__codec%), and from
my limited understading of the playlist db both meta data
and technical info all are stored, meaning in some cases,
tons of unused garbage I doubt there are many people using
%__composer% and %__performer% meta tags that often,
with possible exception of classical music fans, where it
makes a difference that composer was for example
Mussorgsky while the performer was either London Orchestra
or the Moscow Orchestra, each playing the same music with
their own flair of flavour.


Some feature requests :)

Reply #11
I don't know about this %__codec% tag, so I can't really say anything about that.  I'm pretty sure that it isn't storing anything in the database, though.

I can say that the %__composer% and %__performer% tags don't exist.  %composer% and %performer% do, but they exist only in the sense that %snarf% or %blorp% exists.  That is to say, they only exist if you write them into a file.  If they aren't stored in the file, then they won't be stored in the database, so there's no space overhead there.  If you don't have %performer% metadata in your files, then you don't have %performer% metaddata in your database.

I'm not really opposed to a %_filesize% info/meta tag (though I don't see the usefulness of it), but I can see reasons not to include it as well.  There has to be a line drawn somewhere about how much information to store in the database.

Some feature requests :)

Reply #12


thats that I meant ;D  %composer% not %__composer%, this also
explains why my title displaying does not work yet like I want it. ;D
thanks

but the point still stays, your db grows with tons of junk that many
people dont use anyways, through the metadata that is not used.
Ofcourse I see what you mean, meta data is per file, so most files
only store metadata that is used (artist/album/track), storing
filesize would mean storing an extra field for pretty much all files
adding quite of some overhead for all files, whereas metadata is
per file basis, and people by editing tags can remove tags that
they dont like.

anyways, I am happy with answer of 'no', but as I understand
right now its in limbo, neither a yes, neither a no.


Some feature requests :)

Reply #13
Like I said, I'm not against it.    If Peter decides to add it, then good for him (and whoever wants it).

Some feature requests :)

Reply #14
Quote

> dibrom tried to be smart

Is there some reason for your apparent attitude problem?

Similarly, is there a reason that you seem to feel the need to use excessive and obtrusive formatting in your posts?

Quote
this was discussed already, and you cannot calculate file size
based on the bitrate of the file as not all files have a bitrate (or,
to be consistant with VLSI: "not all files have easily calculatable
bitrate" and bothering to actualy calculate the bitrate would be
wasting resources)..


I've seen the discussion, and I've had a similar discussion with Peter.  As it seems you area already aware of the situation, I question your approach to the matter.

 

Some feature requests :)

Reply #15

dibrom, sorry, I should not have said that, and you are 100% right.

From what I gather, %__filesize% type of a tag is on same priority level
as other attributes (read only/hidden/system/archive) or as to volume
name (%__path_volumelabel%) as requested in this very thread by
thetrivialstuff, or as the file dates (creation/modified/access times).

again, please accept my apologies, I dont know whats with me lately
that I seem to get into quite stupid arguments with everyone around me.
(I mean stupid because I dont generally use foobar with the playlist
open anways, and almost never do I care for filesize (and if I do, I
take care of it from wincmd)).

original post corrected.