some suggestions for improving fb2k [0.91 b1]
2006-04-23 01:00:20
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
Wavpack Hybrid: one encoder, one encoding for all scenarios WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file WavPack -c4hx6 (96000Hz) ≈ 768 kbps + correction file WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz