Skip to main content
Recent Posts
1
Support - (fb2k) / Re: Properties dialog refresh failure: bad allocation
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.
3
FLAC / Re: should i use dedicated DAC
Last post by probedb -
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.
4
Opus / Re: Looking at Opus for MP3 replacement and have questions
Last post by ThaCrip -
@adamOLC

Quote
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.

@Trace

Quote
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.
5
CD Hardware/Software / Re: Create cue sheet from EAC log
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?
7
Support - (fb2k) / Re: Track timing with Don't reset DSP between tracks
Last post by Case -
You have length issues when using the setting with DSPs that buffer samples.

A DSP gets N samples from input component at a time and sends it to a buffer. Once the buffer contains enough samples to be processed, processing is performed and as a result the DSP now has S samples to output.

The chunk sizes DSPs get depend on input formats and DSPs that are before them. Usually decoders output chunks at the format's native frame size. And at the end of a track chunk sizes can vary wildly.

I don't know the logic foobar2000 uses to decide when to change output track with this setup, but I'm pretty sure it doesn't split the chunks it receives from the DSP chain. As the sizes from inputs unlikely matches the chunk sizes from the buffer, the lengths will differ.

It could be hacked around for a special case where DSPs don't alter lengths. The converter could simply monitor duration going in and split things after getting the same duration out. But plenty of DSPs change lengths.

Best option for you is to not tick the checkbox and instead use SoX or SRC resamplers that feature signal extrapolation. That way track lengths don't get mutilated and the extrapolation should prevent glitches.
8
Support - (fb2k) / Issue with how Album Artist / Album view works on Android
Last post by Red_Chaos1 -
So I have come across an issue where whether the Album Artist field is populated in the tags for the audio file or not, Foobar on Android still shows the track under (No Album Artist) instead of the tagged artists's folder (the Artist field is populated). The only way it seems this can be fixed is by putting something in the Album field.

This works fine without the Album or Album Artist field populated in Foobar on Windows, as the attached image shows. The track e1m1 by Virt shows up in the under the artist Virt by itself while all the other albums show as folders of their own. Even if I add Virt as the Album Artist, the track still gets listed under (No Album Artist) on Android.
9
Opus / Re: Opus 1.3-rc
Last post by IgorC -
I was just strictly saying 14kbps is THE minimum I would suggest for 'speech' (not music) ...
Now You can go even lower with 1.3 on speech. As low as 13.2 kbps with even better quality (see below).



  • Using wideband encoding down to 9 kb/s

As far as I can tell, this is due to three different modes being used: SILK narrowband up to 9 kb/s, SILK wideband (the slowest) between 9 and 13 kb/s, then CELT from there on. ...
Now 1.3RC1 encodes to SWB/FB at 13.2 kbps as well ( while 1.2.1 codes to WB at this bitrate).
I've noticed it uses SWB or FB on a different samples. I guess it's expected and desired behavior (?)

Overal quality is better actually for 1.3RC.  Though German speech sample was hard to encode. I wonder if it's matter of training and/or tuning.

Samples: https://drive.google.com/file/d/1BMrQlEz01gJVP43PAtYBYiLQUMHlhsLq/view?usp=sharing



Conclusion:
1.3RC1@13.2kbps is on par with 1.2.1@16kbps on speech.
That's 20% of bitrate reduction.  Similar bitrate reduction is observed on higher bitrates (16-40+ kbps)


10
CD Hardware/Software / Re: Create cue sheet from EAC log
Last post by greynol -
A player that emilates the behavior of a programable CD player? Place me in the category of I don't know, I don't care.  I get a CD, I rip it and chop it up and/or do whatever else as I see fit and the CD goes in storage.  The last time I used a CD player was when I moved and that was all I had handy at the moment.

I've had this very discussion countless times over the last dozen or so years. Reading your posts on the aubject feels like a regurgitation of stuff I've posted in the past.  In some cases you were even at the other end.  Not so much because you didn't care, but because you hadn't yet learned.

I've largely bailed from these discussions over the minutiae and rare cases of this or that. I really find no pleasure in them.

There are methods of adding index data from a log file. I've even created such a tool myself.   CT doesn't have this functionality.  My script can be found on this forum, though I can't be bothered to search for it.  AFAIC, there is really nothing more to say about it.
SimplePortal 1.0.0 RC1 © 2008-2018