- It I convert the FLAC files ripped many years ago to WAV (with Foobar2000) conserving the tags and then back to FLAC....then they play automatically advancing the tracks. So it does not seem to be a problem with EaC but with FLAC.
One more clue: the problem seems to be gone after switching fom jscript to chakra engine.
The problem is caused by using different JS engines: Chakra engine provides ECMA-5 support, while JScript provides ECMA-3 (with some extensions). `Array.indexOf` is a ECMA-262 5th edition feature, so it is not available under JScript engine, which is used by default when migrating from v188.8.131.52 to v2.* (v184.108.40.206 used Chakra if it was available though).
Last post by Vexx23 -
Hello, I'm new to this forum, although I am a very enthusiastic audio lover, and I've already read tons of posts on this platform.
Recently I've experienced a very strange phenomenon on foobar2000. I mostly listen to my flac rips of my own CDs, using foobar2000 with an external DAC (Fiio X3 II) but at work I have to rely on simple earphone directly plugged to the laptop. When using an external source for decoding, everything is fine, whereas the problem occurs when using the sound card output (Realtek High Definition Audio) with ASIO: if the playback is paused and then resumed, the playback fast-forwards a lot, to the point of skipping more tracks (although it seems it depends on how long the track is paused), producing a very annoying droning-buzzing sound, which resembles the sound of a turntable needle scratching.
This does not happen with WASAPI whatsoever. With DSD ASIO, there is no skip or droning sound, even though a slight jerk before resuming is sometimes audible. With ASIO driver of external DAC, again, all green. The problem is completely new, I have been listening to albums with foobar2000 for 3 years without this phenomenon. Maybe I messed with some settings, even though I seldom change something I don't know anything about. Please help, this is driving me crazy. I can provide any data about my configuration. Thank you
Last post by Audacious TRex -
Hello, I am not sure this part of the forum is the correct one to post the question, however I try and apologies if its wrong.
I have been using EaC to rip my CDs for ages, I think I started in 2006 ripping them to FLAC files to be played by a Squeezebox. As a result many of my CD rips are now 12 years old.
Yesterday I was trying to figure out why some albums I now play on a Denon DNP-730AE (a DLNA HiFi player) with the help of HiFicast, an android application working as DLNA control point, have such a behaviour:
- If I play an album ripped many years ago by EaC, the player does not automatically advance the tracks. - If I rip again the same album by EaC, (standard options) then the player works fine, automatically advancing the tracks.
HiFicast has an option to "force" the tracks to advance, but I would prefer not to use it cause I'll loose the "gapless" mode.
I do not think I used any special way to rip the CDs many years ago, so I am wondering if somebody can try to explain to me the reason of such a behaviour.
Last post by Peter -
It generally means that the system was not able to hand us the amount memory we just asked for.
This can happen for a couple of different reasons: - Something within the foobar2000 process (main app itself or an add-on component) requested a lot of memory and did not release it, nearing the 4GB barrier that we cannot exceed being a 32-bit application. - Due to some kind of a bug we asked for an amount of memory that we cannot possibly ever obtain, such as a continuous block of 1 gigabyte.
Wow, you are easily offended if that offends you. If you question the difference between the two, old built in soundcard vs RME Fireface 802, then I am certain that you are blind to the difference in quality and could never notice the difference.
You should probably reread the TOS you agreed to when you signed up to this forum. Also back to the insults again.
I don't believe the average users will notice a difference between 64 bit Opus and a 128 bit mp3
That sounds plausible in my opinion especially given the equipment the typical person is likely to use. because listening to Opus @ 64kbps on my PC's speakers(Klipsch Pro-Media (which I had since the early 2000's)), which I would say are above average speakers in general, I think Opus @ 64kbps is up to a certain standard that many would not really notice the difference between that and the higher bit rate files. main reason I say that is because Opus @ 64kbps does not sound obviously bad as I suspect for some people you have to have sound that clearly sounds much worse than the audio CD (or the equivalent) with the overall sound for them to complain and Opus @ 64kbps is no where near that point. hell, I would not be surprised if some people could go even lower than 64kbps and not complain because when not comparing to the lossless file they still sound pretty good overall as they don't stand out in any obvious negative way with the overall sound.
When they say that 160-192 is completely transparent, would 160vbr count as covering up to 192 or it's necessary that I use 192 vbr to cover up to 224?
When the wiki page says 160-192kbps is transparent I just assume it means you set the encoding rate to 160kbps or 192kbps (or random in-between settings which are not worth nitpicking over). I would not worry about the bit rate climbing higher or lower than the selected bit rate as the encoder seems to do that in general depending on the music it's encoding as it might go higher or lower than the selected bit rate, which is normal.
to copy some info directly from the Opus wiki page...
-96kbps = Approaching transparency -128kbps = Very close to transparency -160-192kbps = Transparent with very low chance of artifacts (a few killer samples still detectable)
so given that info, you can't really lose with any of those in terms of overall sound quality. so use 96kbps or 128kbps or 160kbps and forget about it. if your a little paranoid, use 192kbps and forget about it. there should not be much else you really need to know given that info above. hell, for those who like to gamble a bit on sound quality can use 64kbps as I think many will find that quite respectable for portable use and is very efficient to since it's half the storage space of 128kbps and ain't significantly worse in overall sound quality to the average person.
bottom line.... for portable usage(which is the whole point of lossy audio files), I suggest 96kbps or 128kbps and forget about it (I would apply that to Apple AAC also) as those two are pretty safe settings across a wider range of equipment that I am confident would easily please most people.
p.s. I would imagine your going to keep your lossless files (FLAC/ALAC etc) as it would be unwise to delete those especially since hard drive space has become much cheaper over the years. so worst case, you can always re-rip to a different bit rate to any lossy encoder you like in the future if you really need to. so you ain't got much to lose by trying the lower bit rates first (say 96kbps(maybe even 64kbps if space is of some concern)) and working your way up if need be.
NOTE: as far as MP3... I consider 128kbps (basically LAME @ v5) as a minimum given it's not as good as AAC/Opus in general especially at lower bit rates (say less than 128kbps or so). like if I am using MP3 for music, which I don't anymore, I simply would not use lower than LAME @ v5 as when you start to float around 96kbps and lower the differences become more profound between MP3 vs AAC-LC/Opus. so since I prefer 128kbps and less in general, that's why MP3 is pretty much obsolete for me especially given the fact that AAC will play on the vast majority of devices that MP3 will play on and if you ain't worry about hardware support much, Opus is the preferred option since it's the lastest-and-greatest in lossy audio.
Last post by Mike457 -
This may surprise you greynol, but I still burn CDs for playing in my car. My car CD player reads CD-TEXT, so I do like it when I can have it.
As for CueTools, did we definitely settle the question of whether it can properly re-create the correct cue sheet or not?
greynol, I have read many posts from you of late that have the same message. If you think these issues are outdated, have been discussed before or are not worth your time, why bother even posting a response?