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 suggestions for improving fb2k [0.91 b1] (Read 4452 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

some suggestions for improving fb2k [0.91 b1]

I'm now aware about several choices made by the developer or the development team, and I don't plan to object to them. I just have three suggestions that may improve things without increasing the Preference Menu. They're followed by a report of small bugs or issues, probably well-known but I'm not sure...

1 • padding performance with embedded cue files

I played with 99% satisfaction with freshly encoded .flac files. The tagging process -so painfull in the past IMO- was as fast as if the format uses APEv2. I must also say that I set flac encoder to add 16Kb of null data instead of 4...  Nonetheless, it's really excellent (the same can be said for ID3v2 and MP3, I experienced a lot the last week). Congrats!
The only files that had problems (by problems, I mean: full and long rewritting the complete file after a changing the tags) were systematically flac + .cue [embedded]. Always. I have few of them, but it was immediately noticeable (because one losslessly encoded albumfile takes a lot of time to be rewritten).
I think I found the reason: the single file must include all informations (tag) of 10...15 single files. As a consequence, the tag size is way more important than the usual size of a single track file. I may be wrong, but it seems that the 4 Kb of padded datas are a bit short for containing all informations contained within a disc. Could someone confim it? The total size of tags could be checked by Frontah.

If I'm not wrong or if it makes sense, I'd suggest that foobar2000 automatically use an increased padding size when people are using "convert as single file with cuesheet".


2 • padding performance with embedded cue files - Part II

Another point that isn't really optimal: when padding size is too small, the file is completely rewritten. But when I add another field after that, the file is rewritten for a second time, etc... Wouldn't it be judicious to add a new "stock" of padded data when foobar2000 must rewrite the file in order to avoid another long file operation few minutes or even seconds later when the user decide to add or correct something else in the tag?


3 • Adding folders that contain MP3+CUE files

While doing it (see title) two kind of files are added in the playlist: the big file and the splitted file. Example: 60minutes.mp3 and 60minutes.cue [split as 15 virtual tracks] are both imported inside the playlist, which is two hours long instead of one... It forces the user to manually remove all big MP3 files from the playlist, which may take a long time depending of the number of items. If the user don't do it, he must expect foobar2000 to read twice each files (the mp3 first then the .cue...). So it's not really optimal
Suggestion: when a .cue file lays inside a folder, program foobar2000 to not add the reference file inside the playlist. Or something better, if it's not too complicated or time consuming for developers.


4 • Problem: seeking into a virtually (cuesheet) splitted file

Someone already mentionned it, but there weren't any comment about this problem. Why is seeking so sluggish with wv+cue or flac+cue file? It doesn't seem normal, because seeking is usually (i.e. without cuesheet) instantaneous with these formats (I'm already aware about accuracy issues with MP3). Is there an explanation? Are improvements possible?


5 • Problem: WMA wrong bitrate report

I know that WMA support is on-the-road and unfinished, but it may be worth mentionning that VBR-2pass bitrate isn't accurately reported by foobar2000. I've encoded ~200 harpsichord files at 128 kbps with 2-pass; all files are at 128 kbps; foobar2000 reports bitrate from 128 to 180 kbps. WMP, MrQuestionMan, Winamp... have no problem. foobar2000 0.83 is also buggy on this aspect. If 0.9 input component is based on 0.83 one, some changes are really needed.


6 • Problem: limited WMA tag reading

I suppose it's a consequence of this component's youth, but if it isn't, it may be worth mentionning that only few tags are readed by foobar2000 0.91b1. I can see the full set with foobar2000 0.83, Winamp, MP3Tag...


7 • Problem: missing MP3 tags

I guess it's normal, so no need to reply to it if it's the case: the field ENCODEDBY (MP3 with ID3v2.3) doesn't appear in the property list of foobar2000 0.91 b1 but is listed inside iTunes. I read somewhere something like the program can't read some ID3v2 fields, so I guess ENCODEDBY is one of them.


8 • Problem: WavPack hybrid files minor issues

When a file is encoded in the .wv + .wvc form, the bitrate is perfectly reported but not the size (the report correspond to the size of the lossy part). It's maybe intended because 0.83 did the same. A bit more buggy (because unecessary): the correction file isn't deleted when the "delete file" command is used. As the .wvc correction file is totally useless without the corresponding lossy file, I think it should change.
To finish with WavPack: is a complete report of tech data plan to come back, as requested by several users in the forum? With 0.83 it was possible to see which files were encoded with "fast" or "extra" and with or without "asymetric" (extra) compression: usefull to check files before reencoded them if necessary before burning.


9 • Problem: MP3 + Tag size report

In the same vein as previous point, but maybe intended this time: the size of a virtual (.cue) track in MP3 format correspond to the size of the cuesheet file, and not to the reference file as expected (at least expected by me).


EDIT: typo

some suggestions for improving fb2k [0.91 b1]

Reply #1 –
Quote from: guruboolez on
3 • Adding folders that contain MP3+CUE files

...

Suggestion: when a .cue file lays inside a folder, program foobar2000 to not add the reference file inside the playlist. Or something better, if it's not too complicated or time consuming for developers.


I totally agree with it, but it's more or less a feature request.

some suggestions for improving fb2k [0.91 b1]

Reply #2 –
Quote
3 • Adding folders that contain MP3+CUE files

...
Suggestion: when a .cue file lays inside a folder, program foobar2000 to not add the reference file inside the playlist. Or something better, if it's not too complicated or time consuming for developers.


IMHO, it would be better to have some sort of extension exceptions - may be, on per-playlist or per-directory basis. This feature can be used outside of xxx+CUE context - for example, to load all high-quality lossless albums from common music folder, etc. May be, this can be implemented as a plugin?

some suggestions for improving fb2k [0.91 b1]

Reply #3 –
I totally agree with 1 and 2.  Sometimes I have to wait 5-10 minutes for it to update an embedded cue in a flac file.

3 would be nice too.

Ed

some suggestions for improving fb2k [0.91 b1]

Reply #4 –
3 & 4 are pretty big obstacles to proper cuesheet support IMO.

some suggestions for improving fb2k [0.91 b1]

Reply #5 –
Could you elaborate?

some suggestions for improving fb2k [0.91 b1]

Reply #6 –
Quote from: guruboolez on
Could you elaborate?


Well, 3 is a problem because if I select a folder with a few albums containing cuesheets, each one will play twice.

4 is a problem because it's damned annoying.


From a user point of view, both of these seem like easily fixable annoyances.

some suggestions for improving fb2k [0.91 b1]

Reply #7 –
First, thank you *very much* for including WMA support in v0.91. I do agree on problem #6. There are several WMA tags which are not being read. The most important for me is WM/CONTENTGROUPDESCRIPTION. This is the WMA equivalent of the TIT1 tag of ID3v2.3.

As a professional DJ, I use CONTENTGROUPDESCRIPTION daily to group my music into crates and other meta groups. I pass it on to an OGG file when I compress files to my laptop to spin with Serato Scratch Live. Then I can lookup all the songs/records that I bought at a certain day or record store.

This issue of "what tags to store in the db" and "what tags maps to what friendly name" is a common problem that I've seen with all players, encoders, etc. I keep recommending the following feature and no one has so far considered it. What might this feature be???

Let the user decide. Especially the power users of Foobar. Have a mapping file (which has defaults setup in the initial installation) which for a given filetype:
1. Lists all tags to load into the foobar db
2. Maps those tags to friendly names

In this way, the user can choose to load these less used WMA tags and map them to whatever friendly name they want. This can be then access using %tag% or $meta(tag).