Last post by Neuron -
The main reason I haven't switched to Opus is that I heard somewhere that it reconstructs high frequencies so that they are basically synthetic..like in HE-AAC, for instance. Is this a correct assumption or not?
Nah, it does not. It has a special "band folding" method of encoding high frequencies at low bitrates, but it always operates at 48 Khz. It does not bluntly downsample it to 22 Khz and then fake half of the frequency spectra. The downside is that under 48 kbps it sounds more "cassetty" and muddy than HE-AAC, through in my opinion less artificial (HE-AAC sounds metallic to me at low bitrates).
Yeah, I came back to share the fonts after finding out it was those, anyway you can download them on megafonts.net (don't know if I am allowed to link them)
It seems to be for everything though @marc2003 (play/check), anyways thanks really appreciate it.
Last post by Porcus -
It is worth noting that the gains from mp3gain are not very accurate compared to modern replaygain tags."not very accurate" could mean at least one of two things here. The first is not up to discussion: due to the MP3 internals, volume can only be shifted in fixed increments (1.5 dB IIRC), while an RG tag allows for finetuning.
But a different question is whether the loudness measurement - how much should one apply - is up-to-date. Opinions differ on whether the original RG specification or the EBU R128 specification is better at differentiating loudness.
Wingdings 3, characters u and w
Thanks. How was this solved? How can I use it in LameXP or any other GUI? How much does it decrease quality over no-fix, and at what bitrate does this version achieve transparency with the fix?
MP3 is the worst lossy codec ever released, so move to Opus ;
This is just wrong. VQF, WMA, Qdesign... were far worse, and when you consider how old mp3 is, the fact it can compete with aac and ogg as long as you use VRB LAME encoding it is amazing actually.
What's the font for the play button? https://github.com/19379/foo-jscript-panel/tree/master/foo_jscript_panel/samples/jsplaylist-mod
I though it was guifx, but it doesn't seem to work
ThaCrip, the wait was referring to the last part, about the encoders.
foobar2000's default \encoders folder with the installation is inside %localappdata%, when portable it's inside its own folder, wherever the folder may be.
The 64 bit setting is already set, for all the encoders that have the option, I think I was the one to suggest it probably 2 years ago so no extra step there, same number of clicks to get it to work like the 32 bit. And there is quite a speed difference if you have a more powerful i5/i7 IIRC.
You are a little too jumpy to recommend but you're not experienced enough to recommend a bitrate, you can suggest buy not recommend, I see a big difference there. Don't take it personally, I think the forums needs to see more experience, more abx logs, months of testing and relax and retest etc. I don't recommend anymore either, that's why there are recommendation pages for all the lossy codecs, point the users there instead of confusing them more with "my recommendation here and there".
This is what I do, I have few rules:
I suggest AAC from ~96 up, Opus same or even ~80 up at this point since I was able to hear some stuff at ~64 but I have to test deeper, MP3 from V4/V3 up with personal tests to see if V4 is enough, the rest is up to again, more personal tests from the user. I don't suggest any other lossy codec but if you want to use Vorbis or MPC or LossyXXX whatever. For lossless I suggest FLAC, default -5. WavPack or ALAC only on few situations.
ThaCrip, usually wait until they ask to provide info they may not need because they may confuse instead of helping.
I mostly said what i said (with the whole Apple AAC @ 128kbps or 256kbps) as a general guideline for someone looking for a simple answer to the OP's question which i suspect a fair amount of people would like to know. so for some casual person who stumbles into this topic that's why i said what i said as it gives them some good basic advice.
foobar2000 looks automatically for the \encoders folder, why would you made a C:\TEMP or any other folder outside where foobar2000 is aleady pointing at? Just copy the QTFiles/QTFiles64 inside the foobar2000's configuration's \encoders folder or inside the foobar2000's folder directly if it's in portable mode.
I would have to test, but i think Windows 10 might complain a bit as i think when i delete something from there (i.e. C:\Program Files (x86)\ ) it asks to confirm etc. that's why i just did things in a C:\TEMP\ folder initially and then a simple copy/paste to Foobar2000's encoders folder. but assuming Windows 10 does not complain about running that makeportable.cmd file from within C:\Program Files (x86)\foobar2000 etc then it would actually be quicker to just copy the 'iTunesSetup.exe' and 'makeportable.cmd' file to Foobar2000's 'encoders' folder as that would give people less steps to do and would save a little time. but i just played it safe and did something i know will work.
I'm telling you by experience, wait until they ask for the extra step so you can provide detailed info for exactly what they need in that particular case and you eliminate the risk of providing unneeded or misplaced information in advance.
I believe you, but like i was saying what i replied with is some good basic info for someone using Foobar2000 with general FLAC to Apple AAC conversion and gives the info needed to get things up and running, pretty much. it can be useful for people who might stumble into this site looking for some general guidelines to go by with the Apple AAC @ 128kbps(storage space is of some concern) or 256kbps(space is a non-issue). basically pick one of those two settings and forget about it sort of thing.
Also you excluded the 64bit option which is faster, not by much but I prefer it
I excluded the 64bit simply because using 32bit is safer and less steps needed to get it working and, as far as i can tell, the 64bit encoder requires the 'custom' option to get working in Foobar2000 (someone correct me if i am wrong) where as with the 32bit you can use the built-in stuff from the drop down menu and use the slider to adjust quality settings etc.
plus, the 64bit speed increase seems to be negligible over the 32bit, at least on my i3-2120 CPU. i have not measured anything concrete, as i was just looking at encoding time on a random album in 32bit and 64bit, but i want to say for a typical album it 'might' have been a few seconds or so which is a non-issue as if we went from say 1min to 30second encodes for a full album, or something like that, then it might be worth the hassle to use 64bit.
I will use iTunes AAC encoder via qaac (under EAC).
You can do what you want but i think Foobar2000 is your best bet for general FLAC to AAC conversion. EAC is good but it's primary use is to extract audio from a CD. but outside of that, Foobar2000 is better for general audio playback/basic conversion of audio files etc.
just some thoughts.
I found that on my most demanding recordings I can barely ABX 128k AAC encodings from the CD original. I have been using 256k VBR just so that I don't even worry about it, and have never been tempted to look back.
Basically this plays inline with my recommendations with Apple AAC above.
128kbps is basically safe enough for most people, especially for those who want more efficient use of their storage space, but for the type who wants to use lossy audio but is a bit paranoid about sound quality then using 256kbps is what you want to use.
with that said, i am sure there are some people who might like to experiment a bit and might go with something in between. but i figure those types probably will do ABX tests etc to really fine tune things to their own personal hearing. but i figure most people ain't going to want to spend too much time on these things which is why i figure the 128kbps/256kbps rule is a good guideline.
it seems legal to use no separator for artists, like in this release but the result after writing the tags to the file is not very convenient. (we could use a script "Skip multiple artist fields", but SPACE is a bad separator for names.The join field is not supposed to be empty as per Discogs guideline 2.6.1.
I suppose you could change your formatting string to replace empty join fields with a default such as "," or ";" if this was a big problem. Personally I would probably just update this release on the database.