Wow, I've been running CUETools 2.1.5 in kvm (Linux VM) with XP for years. Running CUETools 2.1.6 under wine 3.0 on the same system is 7.5x faster (6 seconds vs 45 seconds) for a verify on the same album. Fortunately I did not encounter any crashes using wine, all the config screens worked fine. The font size is microscopically small on my 4K monitor though.
Last post by Chibisteven -
The cuesheet format is used when joining multiple files to a single file in foobar2000's converter.
Cuesheets are designed to address audio as 1/75 of second for a single frame. That's 588 samples for standard CD audio (44.1 KHz). If we take 96 KHz and divide it by 75, you get 1,280 samples per frame.
The source in particular as with any self-recorded albums or downloaded music often isn't set up with this in mind, so you get time variations like this. If this actually happened with a CD rip from a lossless source then I consider it a bug but since this doesn't seem to be the case here, it's simply the limitations of the cuesheet format manifesting itself.
The time format for CDs is MM:SS:FF which is what the cuesheet format itself uses.
The workaround is to use output as individual files option instead when using the converter. Track lengths will always be the same here, assuming it's just a straight conversion between two different lossless formats (compressed or uncompressed). This should avoid rounding errors.
you could use kode54's normalizer R128 DSP which applies normalization/ReplayGain in a non destructive manner in realtime on files, without them being tagged as such. You can even do so on Internet streams or emulated content.
It uses a bit of lookahead, and tries to keep the volume level from getting too loud, or staying too quiet for too long. It doesn't compress dynamics in a rapid fashion, though, or in a multi-band equalizer sort of way, either.
hey that's just awesome. a real time normalization is just exatly what i need. i will check this out right now. sure, in real time the every audion signal information, whether it is a quiet part or a loud part, will just be normalized without the differences between. but let me check it.
btw i tried m-tags and it is great. i just checked it. i am sure there is a way to read the tags from the files and copy them fast into the m-tag file, since foobar shows only tags from the m-tag file when using m-tag.
I want to convert my ~2k files with AC3 5.1 and AC3 2.0, should I wait for opus 1.3? What settings do you guys recommend to opus 5.1 and opus 2.0 to achieve transparency ? File size isn't really a issue here, I just want to have a library fully open source
The only problem I had was that configuring it as I wanted crashed on some steps.
Do you know where I find this settings.txt file? I have CUETools running in an XP VM. I would love to not have to use a VM to run CUETools, it's the only WIndows program I use. Thanks!
If you run it balanced, then it will generally have lower noise. Most home audio runs unbalanced, though. And it's not a problem. Who complains about the noise their AVR, say, puts out?
So, if you can run it balanced, great. If not, run it the way millions of humans do - unbalanced.
Chromecast (all models with up to date firmware) has excellent native Opus support, including multi-channel. There's a bug with h264-with-b-frame/Opus causing stutter but it will be fixed in a firmware update.
Nice, that's good to know. Do you notice any issues when streaming to something that has to transcode the audio to other format? I guess that can't be worse than transcoding other lossy codecs right?
Last post by cyano -
Versions: 1.3.17 and 1.4b3
Problem: Joining multiple tracks corrupts track lengths in high sample rates
When multiple 96/24 files are merged with "Generate multi-track files" option from the internal converter module, the sample lengths of the tracks are not preserved. The conversion is a FLAC-to-FLAC (v1.3.2) conversion.
The highlighted tracks are from the merged file. With the faulty conversion, some of the tracks (2, 4, 6) now have longer lengths, and some of the tracks (1, 3, 5) now have shorter lengths.
There should be no change.
Because FLAC stores the track offsets as sample numbers, I think this could be related to fb2k writing the cuesheet in CD-DA compatible format (min:sec:frametime), rather than the FLAC itself.
As far as input sensitivity goes, for the XLS series it is 0.775 or 1.4 volts RMS for full output. Connecting an unbalanced input cuts that in half, so the 0.775 volt setting is the one to use, and it gives you an actual 1.5 volt sensitivity which is pretty common for consumer amps. IOW, no problems expected on this front.Just want to confirm that I understand. Using the unbalanced connections with the .775 setting; will that lower the S/N ratio?; If this is so will it be a problem for hiss?