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.
Recent Posts
2
3rd Party Plugins - (fb2k) / Re: foo_musicbrainz
Last post by MordredKLB -
Quote from: Habanero on
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.

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.
Why is it that album/artist doesn't work but catalog number would? Is it because you're translating names?

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.
6
CUETools / Re: Post-rip Verify against AccurateRip Database
Last post by sundance -
For my understanding:
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?
7
FLAC / Re: Retune of FLAC compression levels
Last post by Porcus -
I loosely tested fixed predictors. Don't know if I can trust the timing differences, but fwiw: Block size 2304 looks good in this build too.

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."
8
General - (fb2k) / Re: FFmpeg Decoder Wrapper (foo_input_ffmpeg) passthrough output
Last post by gorman -
Quote from: wojak on
Quote from: gorman on
Quote from: wojak on
I would very much like to see the passthrough option in Foobar for all Dolby and DTS signals (DTSHDMA, TrueHD, DTS96/24 old-lossy ones and all others).
As far as Dolby Digital, DTS and DTS 96/24, you can get passthrough by NOT installing AC3 and DTS decoders in foobar2000 and using AudioMuxer and its "Convert AC3/DTS to SPDIF Wav/Flac" function. It encapsulate the AC3/DTS content in a WAV file you can then compress to FLAC, in order to properly tag it.

foobar2000 decodes the FLAC and leaves the result untouched, sending it bitperfect to your AVR. Obviously you need to use WASAPI output and leave fb2k volume at 100%.

Which is pretty much what I'd like to find a way to do with FFmpeg Decoder Wrapper for object based surround content. Because while DTS-HD MA and TrueHD can be decoded losslessly (so I think, at least) the object based surround extensions of Atmos and DTS-X are completely lost in the process, currently.

Thank you for the suggestion but to be honest I do not see a point in installing additional programs/plugins, "cheating the system", encapsulating something into something and so on just to get a pasthrough. What I need is foobar being able to just not "touch" my files, just play them - for example Bluray or DVDV or DVA files with different audio streams. I do not intend to rip them, demux them, convert them and so on just to get proper playback. I would like just to play them and get what they are without altering.
So the best solution is to implement passthroug with option to enable/disable it (so FB would decode the files or pass them through).
Not disputing your wishes... my request is more conservative, recognizing that such use would not be widespread. Don't mistake this for me not appreciating what you wish, I'm simply trying to be realistic in my request.
9
MP3 / Re: Why does LAME 3.90.3 sound so good when compared to newer LAME versions?
Last post by ktf -
Quote from: ClearSky on
Ok, I did a quick ABX test, and I couldn't notice the difference.
Thanks!

So, it seems your own ears have tricked you. This is nothing out of the ordinary, but many people find it hard to believe or hard to admit. It might very well be you expected something to be different, or noticed something you hadn't heard before while listening. On subsequent listening, your ears and brain will 'hear' something because you expect to hear something. AFAIK this is called expectation bias or confirmation bias.

Because it seems no human is exempt from these biases, it is important to use tools to eliminate that bias, like ABX. In the past I made a lot of live recordings of musical ensembles, and often I tried to make mixing decisions blind, by placing two mixes next to each other, switching back and forth quickly a (random) number of times with my eyes covered, and then listening switching between both mixes (still eyes covered), making the decision not knowing which one I was listening to. I felt great working like this, but that feeling might be confirmation bias as well of course  :))