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
5
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.
9
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?
10
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."