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.
General - (fb2k) / Re: foobar2000 v2.0 bugsLast post by grimes -
- Save metadb.sqlite
- remove metadb.sqlite
- Remove music folders in Preferences|Media Library
- Add music folders
General - (fb2k) / Re: foobar2000 v2.0 bugsLast post by Andy Foo -
Do you have a corrupted Media Library?
Thanks for the suggestion.
I will try to remove and rebuild the library in the 64 bits version. In all other versions of Foobar (1.6 and v2 32 bits) it works fine with the same source files.
3rd Party Plugins - (fb2k) / Re: Playlist Organizer (aka foo_plorg) replacement on Jscript Panel 3Last post by etip -
Version changes :
- bug fixes : Display of a selected folder/playlist in the header area (@paul eye : It should be ok now)
- The focus will now jump correctly to the searched playlist. @frogworth : let me know if it works
3rd Party Plugins - (fb2k) / Re: foo_musicbrainzLast post by MordredKLB -
Thanks for the great component! I'm thiiiis close to no longer needing to use Picard anymore (or at least for adding MBIDs quickly). Picard's great, but having to open it up every time and search for the album is a pain.Why is it that album/artist doesn't work but catalog number would? Is it because you're translating names?
I opened a Git issue, but I'll repost it here for discussion, etc. Searching for album via catalog number, and "Preserve this field", would be really useful for me. Often times I don't want to change the album name or the track titles because I have JP albums with EN names instead.
In my own personal tagger I have a method for getting the original artist for songs so I can determine if it's a cover or not. Isn't perfect but works pretty well. I might look at implementing that for this component. Would that be beneficial?
I'm not sure I want to add workcomment/recording comment though. I'll consider it, but I need to do some more investigation.
Your "preserve this field" idea is actually a huge shortcoming of this component as is, and again something I did in my own personal tagger. The big hurdle is how to convey that to the user in the limited dialog space we've got. It's particularly difficult for any of the fields in the grid below. Maybe some kind of right click menu, that's great for a single field, but the UX for that kinda sucks if you want to preserve 5 fields or whatever.
CUETools / Re: Post-rip Verify against AccurateRip DatabaseLast post by korth -
yes (without checking your math)
b but on-the-fly (CUETools always processes the audio as a continuous Image)
General - (fb2k) / Re: foobar2000 v2.0 bugsLast post by MaFred -
General - (fb2k) / Re: FFmpeg Decoder Wrapper (foo_input_ffmpeg) passthrough outputLast post by gorman -
So probably my request is useless (not that I'm sure that component will do what I need).
Edit: tried experimenting a bit with ffmpeg, no luck so far.
CUETools / Re: Post-rip Verify against AccurateRip DatabaseLast post by sundance -
Is it correct that the PREGAP format is mm:ss:ff (minutes, seconds and frames)?
The offsets reported in log are in samples, right? (So offset=692 means 692/44100 = 15,6916 msec @ 44.1 kHz sampling rate)
Talking about (uncorrected) ripping offsets (in some of my earlier rips):
I learned that CueTools can be used to correct this offset. Is is correct to assume that CueTools (if supplied with an m3u playlist file, Action = Encode, Mode = single file and an offset of 692 in the "Extra" field) does:
a) NOT cut 692 samples at the start of each audio file and add 692 samples of digital silence at the end
b) BUT: combine all files from the m3u to a single audio file, THEN do the stripping/appending and split this "shifted" file into single audio files again?
FLAC / Re: Retune of FLAC compression levelsLast post by Porcus -
But I guess there must be some "executive decision on principles" under all this, and maybe there is little use in trying all sorts of timing tweaks until those are sorted out.
So @ktf , could you provide some input on the following - including "put off that test until next build is posted here" if applicable:
* -0/-1/-2: is it "1152 or 4096, nothing else"? (If so I won't do more 2304s on more computers.) And it is clear that nobody needs -0 to be dual mono? (If so ... no need to test dual mono, it performs bad.)
(* -3: I kinda feel less worried over joint stereo here. If some device is crippled enough to need dual mono, then would it even use LPC frames?)
* -4 vs -5 vs -6: You are proposing to change -5. 1.4.2 at -6 isn't good IMHO, so proposing that as a new default does call for testing I think.
But someone in the system might have made a decision what is more "sacred", if anything: The default setting, or default being "-5"?
Arguably, if one wants to change the default setting one might as well let new default be "new -4" if that is more convenient. The only ones who should care are those who encode with an explicit "-5", and if they give explicit parameters they could read manuals.
* -678: 1.4.2 was a slowdown (the double precision fix), so to ask outright: does -8 have to become faster? Do you need to stop the complaints about 1.4 being slow? If that is a must, then it looks good - but if on the other hand you do not want complaints that "1.4.2 compressed better!!" (from people who don't calculate ratios and see that the change is not much to whine about), then more tweaking could be done.
* The -l32 on high resolution ... I don't think it is ready. Not as high as 32. Could do more testing, but if you are already reassessing the order selection algorithm, then I won't bother to do more testing yet. (An aside, your explanation at the bottom here with link to code seems to explain a jump between 16 and 17 - but the jump showed up between 15 and 16.)
Also the concern about "-8e", but that is just as much over "-8p", those seem to be quite comparable in time consumption.
A note on why prediction order matters: In the short 96/24 test above, -8pl17 and -8el16 took the same time, the latter improving 0.17% over the former, which in turn improved 0.06% over -8l17.
Long rambling but question was: are you already working on the order selection code?
* Is a "-9" off the table? Could even be undocumented in the short help. I was thinking:
"-9 (experimental): same as -8 for standard resolutions. For higher resolutions, employs settings likely to change in future versions."