I have a digitised cassette tape recording (not my tape) in flac (44.1kHz / 16bit) that I've converted to wav for editing (remove non-program specific start and end audio).
It's a very good recording hitting the ~15kHz limit that the BBC imposes on FM transmissions, but more importantly sounds great for a cassette tape FM recording from 1996 with little hiss.
Looking at the spectrum I can see a pilot signal at ~19kHz (see here for a screeny).
My questions are:
1. should I bother to run the wav file through a lowpass filter to get rid of the pilot signal?
2. If so, how is it best to do this? I can do it in Audacity but thought that using a resampler like sox might be better as suggested here. If so, are those options correct? I'd use 0-16000 for the filter of course.
I will keeping two versions of this file:
(a) a lossless (flac) archived copy and
(b) a lossy (mp3) copy that I'll run a 16kHz lowpass filter on when creating it
Isn't placebo amazing? It's one of my favorite fields to study. Sorry about the link, it happened many times with this new forum, maybe they'll fix it so it becomes something automatic.
I did say thank you for the lesson and this is what i have learnt
Like mentioned... just use FLAC 8 as any computers likely to still be in use you might as well save as much hard drive space as possible as it only takes 1min or less (on my i3-2120 CPU, which is decent but nothing special) to convert a entire album (even if that album is 80min or close to it) from FLAC 8 to your typical Apple AAC or LAME MP3 etc in Foobar2000. even when converting from WAV to FLAC is very fast (clearly faster than lossy conversion) when the WAV files are already on your hard drive.
with that said, from what i have noticed... FLAC 5 vs FLAC 8, there is roughly a 3-5MB difference in file size between the two for full audio CD's. but considering how fast computers have been for quite some time now you might as well just use FLAC 8 and be done with it as if there are any speed differences it won't really matter since when you convert from FLAC to AAC/MP3 etc your limited by the lossy encoding speed and not the FLAC decoding speed anyways and even with that we are still only looking at about 1min tops to encode a entire audio CD from FLAC to AAC/MP3 etc and i don't even have a monster CPU either even though it's decent (i.e. i3-2120. basically dual core but windows see it's as a quad core due to it's hyper-threading technology). but those who have quad or six core CPU's (or more) will probably be around 30seconds or less for a entire 80min audio CD i suspect which once you start getting into that kind of speed your basically more limited by how fast you can move you hands to create folders within Windows Explorer than by the actual encoding times of the audio files.
also, i don't how how true this is (someone correct me if i am wrong) but... one random site i read online said, "There is no decoding hit by using the most compressed value of 8. For a little processing time up front (encoding) you get a smaller file with no extra time needed to decode." ; so assuming that's accurate... decoding times are the same regardless of compression level of FLAC as it's only the initial encoding that slows down a little. but given the speed of modern computers it's a non-issue and you might as well save the disc space and use FLAC 8. come to think of it, even if that's strictly not accurate (like with the speed the computers CPU decodes the FLAC files) it won't really matter (maybe very little) because when converting any FLAC file (like FLAC 5 or 8 etc) to a lossy format, the lossy encoder speed is the limiting factor on things anyways. even if there is a difference in real world time to make your lossy files, from FLAC 5 or FLAC 8 etc, i would have to assume it's negligible(basically a non-factor) on a modern computer simply because it's going to be less than 1min on a lot of semi-modern/modern computers with a lot of audio CD's anyways, even with FLAC 8.
but as far as general learning... i recently made a account here even though i have been browsing here on and off for years now as it seems like this place is a step above a lot of sites (it's pretty much THE standard for what this site is about which is audio related with encoding lossy files and the sound quality of them etc) as you see a lot of 'claims' on random websites over the years that you know are BS given what i have learned here. a little side note... it's funny how many people still seem insist on 320kbps MP3 (or other really high bit rates) which to me is a waste of storage space, especially the 320kbps, as LAME v0 (245kbps average), which is LAME's highest VBR setting, basically gives you the same thing but with a more efficient use of storage space and it seems even those with 'golden ears' tend to praise LAME v0 (outside maybe a rare occasion). but in my opinion... Apple AAC @ 128kbps is the sweet spot between sound quality/storage space for AAC-LC, and has been for years now, as i can't see using roughly double the storage space (which seems to be what iTunes Plus does with it's 256kbps setting) for a minimal increase in sound quality as it sorta defeats the purpose of using lossy encoding as if someone is THAT concerned with sound quality they might as well just use FLAC. with that said, it seems like even for the 'golden ear' type of people that AAC @ 256kbps (i.e. iTunes Plus setting) seems to be transparent on everything(?(or very close)). so i guess for those who care very little about storage space, and want to use a lossy encoder, then it's hard to say anything negative towards the 256kbps AAC listener.
p.s. that quote above was from here... http://www.forums.stevehoffman.tv/threads/if-flac-is-lossless-why-does-encoding-level-matter.140499/#post-3249182 ; which is from Feb 2008.
@eahm ; funny little posts there you linked to above ; but at the same time, all of the time they wasted and what's even worse they believe it beyond a shadow of a doubt ...
... "Well I am absolutely certain I can tell [the difference between FLAC and WAV]." & "Flac is a bit drier, a little sweeter perhaps and I think details better resolved. Wav seems fuller, richer and perhaps a bit more dynamic." ; guaranteed they never heard of a ABX test which removes bias and cuts through the BS real quick like.
it's sorta like those who pay extra $$$ for HDMI cables that claim to give better picture etc. it's a waste of $$$. it's like those who pay say $100 for a HDMI 'gold' cable etc and suddenly think there HD is much better vs one of the cheaper/typical HDMI cables.
p.s. your second link does not work when clicked because it's got the "," tied to the link. just space it next time and it will be fine as once i remove that "," your second link works.
The reason i compiled the binaries by myself is that MSVC or ICL builds often do not perform as expected on the older AMD system i am using.
This is also the case for the Chocobo1 build. I'd like to have generic builds with a balanced performance across several platforms.
According to the website the modified AltiVec/SSE Optimized LAME Encoder version is specifically targeted on Intel processors (...binaries and
patches optimized for Intel and PowerPC G4/G5 processor.). As the GCC compiler is used, this one is quite speedy even on my AMD system.
Hmm - right now i have no idea why only the SSE2 version of GoGo crashes. I added this just for fun anyway...
Where are the stats info stored? In the .cfg file? Inside the index-data folder? I see there is another file now.
Thanks for the update, finally i can remove the "3.100 alpha2" from my laptop
Thanks, testing in few and btw ...the first two links have Win binaries.
WTF? The first one I tried goes at 450x. I'll keep testing then, thanks for this pack. Oh ok, GoGo is LAME 3.88.
gogo-313-sse2.exe give an error and the process stops, using Windows 10 Pro 64bit, I now realize that it was probably made for older Windows, right when it came out, since GoGo hasn't been developed in a long time.
Other 3.100 bins have similar speed to tmkk (but tmkk is still a little faster), I'll keep tmkk for now.
Last post by Surfi -
Even EAC's "CD Layout Editor" has "Add 2 Second Gap On Append" enabled (checked in "Layout" menu) by default after a fresh installation. The opposite should be the case, I think.
I was too impatient waiting for Windows binaries - here https://1drv.ms/u/s!AL7dMfpnifu2gw4 are my latest binaries of LAME 3.100, LAME 3.99.5 and GoGo-no-coda 3.13.
Compiled with GCC/MinGW using the original source code and safe compiler optimization flags. The binaries should perform equally well on Intel and AMD platforms.
Now using opus on a clip zip with no issues. Rockbox 3.14. Grateful to all.
I think that pretty much confirms what i suspected as i think you got a noticeably faster CPU (i think it's around 240Mhz but i can't seem to find anything definitive looking around on Rockbox website) than what our e200 series v1 players do which appears to be only 80Mhz.
with that said, i would not be surprised to see Opus use noticeably more battery than AAC-LC does on your device even though Opus functions well for you and there is apparently no laggy menu's while playing Opus encoded music. but i guess as long as the battery runtime does not drop off too much then you ain't got much to lose by using Opus over AAC-LC, especially if you don't care about the whole wide compatibility aspect of which AAC-LC will always beat everything, outside of MP3 of course. but i figure at this point in time it's not likely many devices that work with MP3 but don't work with AAC-LC are still in use anyways.
but i guess when it comes to the whole Opus vs AAC-LC (Apple AAC basically)... i suspect the trade off boils down to less battery life for probably a little better sound at the lower bit rates (when choosing Opus over AAC-LC). but i am not sure how Opus compares to AAC-LC once you get into the 128kbps+ range. but i figure even if Opus wins, it's got to be very little difference to most people in the real world as i would imagine even those with the golden ears etc who can detect artifacts at the 128kbps+ ranges it's probably something they got to be really focused on(?) and when just enjoying their music it would be negligible difference(?). that's basically why i feel Apple AAC @ 128kbps (q63 TVBR) is a safe setting (considering the public ABX test link below @ 96kbps from late-2014 that i linked to below) and is a nice efficient use of the encoder to as your not using excessive bit rates to clean up tiny things.
but as far as the 96kbps range... taking a quick look on these forums i found a public listening test from late-2014 that shows Opus was #1 with Apple AAC being #2 and that was before the Opus v1.2 release earlier this year which seems to further refine the sound quality of the encoder even though, from what i have read, most of the Opus v1.2 improvements are at the really low bit rates (say 32-48kbps or so, maybe 64kbps-ish a bit etc) which i would not be surprised if it squeezed a little more out of it. but like mentioned... with modern encoders like Apple AAC or Opus in the 96kbps+ range they are quite strong to where they simply cannot sound bad, even amongst those with the golden ears. so while these modern encoders are solid, to bad they were not this way say 10 years ago when storage space was not cheap etc as back in those days really low bit rates would have been more appealing as even being able to use 128kbps, like we can today (and for at least most of this decade), would have been nice as, if i recall correctly, using higher bit rates back in those days were somewhat required to get consistently good sound basically.
hell, just last night i was trying to do a ABX test on a random song i had with Opus @ 64kbps (in comparison to the FLAC obviously) and when i started the test i was confident i was hearing a difference for the first 4-5 choices (i was attempting to do 12 rounds in the ABX test) as i made my picks fairly quickly but after that i started losing confidence again (as i was no longer confident i was hearing enough of a difference to make a choice that i was confident in making) and stopped the test. but even assuming someone gives me the benefit of the doubt (in that i was hearing a difference), during the times i was confident i was making the correct choice, the sound was not that much different in that if i was not hearing the Opus @ 64kbps file in comparison to the FLAC file i doubt i could notice any differences when listening to the song straight up as the overall sound seemed consistent but there was something you could notice (i don't know how to describe it as i don't know the technical terms), like something in the overall sound altered just a little to be able to slightly detect it. but this is why i suspect, to play it a bit safer, if i had Opus @ 80kbps i would not be surprised if i could not ABX that, at all. so if that's true, then i would be very similar to some users around here who feel Opus @ 80kbps is a fairly safe setting because even if we could notice it at that point, it would likely be in that major focusing level of concentration etc which when your at that point, or even close, it's pretty safe to say the overall sound is pretty stable/good and likely will be on a wide range of music for us.
p.s. here is the 96kbps test i was referring to above... https://hydrogenaud.io/index.php/topic,106354.msg874674.html#msg874674 ; side note: you notice MP3 seems competitive there (but still a bit worse) but it's also using noticeably higher bit rates. so it's sorta cheating to stay competitive. hence, Opus/AAC-LC are just better as they use noticeably less bit rates to achieve similar sound quality.