Last post by 4season -
For what it's worth, I recently purchased a Marantz NR1608 cinema receiver, and it has a number of useful features:
It's Audyssey room correction can be used with as few as 2 speakers.
Speaker-minus outputs are all tied to chassis ground, and chassis isn't tied to earth - am thinking this may be particularly helpful combination of features when pairing with active speakers via home made speaker-to-line adapters such as those suggested by Genelec here.
I got mine at a considerable discount because a newer model had just been released. I could have saved even more by opting for the less expensive NR15xx-series which supports a maximum 5.1-channel configuration, but I thought I might like to fuss with Dolby Atmos at some point, so I opted for the NR1608. Current NR1609 adds Amazon Alexa (ugh) and a phono input, neither of which seemed like they were worth a $250 premium.
but, in computer terms, each lossless codec is also container (as it is MP4 or MKV for example). It will play anything what you put-in and will never take care about it's quality. Flac can decode PCM on the fly but loss in sound quality is enormous: nearly twice!
Last post by [JAZ] -
I installed Spotify some time ago and uninstalled it. It was starting in place of my preferred application and I remember that it was playing the same song, but I can't be sure now if it was playing from the last place or not. (Uninstallation wasn't perfect, since then the default player didn't want to start automatically. Recently it had some updates and seems to start automatically again)
Still, it might simply be a feature of the player. As an example, if you play a youtube video and quit when it hasn't finished, you can start it from where you were when open it again. Spotify might do that.
Last post by Case -
1. It uses 32-bit floating point at the sample rate and channel count configured for your device. The component will automatically resample and downmix channels if needed. 2. Event. 3. It's the opposite of Exclusive mode. There can be only one exclusive mode WASAPI session open on a device and all other sound sessions are blocked. Shared mode allows multiple sessions to share the device, they just need to take care to output sound at the format the mixer is configured for.
Thanks for that. So i can call FLAC a container best suited for PCM audio
Why do you want to give your own name to anything? Just learn to use their real names and description. Much easier for the future. Developers calls their Flac "codec" (as one guy here mentioned above) but, in computer terms, each lossless codec is also container (as it is MP4 or MKV for example). It will play anything what you put-in and will never take care about it's quality. Flac can decode PCM on the fly but loss in sound quality is enormous: nearly twice! Flac best attitude is lossless file compression so instead of 1,000 CD albums, you can keep 2,000 CD albums in the same space.
Idea is to stop understanding Flac as the guarantee for inside music quality. That's all. From that point of fiew, Flac is stupid. Its simple do not care what is inside it. Is it CD real or decoded to WAV from MP3 file, you can check out with some utilities as aucdtect or simple visually as here on the screen.
Imho, source for both screens is the same (some losy archive) only the first one is artifically "colorized" as kode54 mentioned. "Most lightweight way to carry the bits" is nicely said too.
All my music collection, if is not burned to CD or DVD. is in Flac.
Last post by GCRaistlin -
The new version works correctly, thanks.
In comparison to WASAPI output support 3.3 plugin, yours has less options to setup so I have a few questions: 1. What output data format does it use? 2. What mode does it work in - push or event? 3. What does "shared" mean in the names of output devices?
Of course that would be lossless. RAR doesn't alter the sound file at all.
It can't "WOULD BE". Rar IS archivator which use lossless compression algorithm. That programs can't be changed in dependence of what file type they did archive (WAV or MP3). Flac can archive images. And use lossless compression algorithm too. AAC use losy compression algorithm. Etc etc... By the way, Rar CAN archive wav. Compression will be very small and size of source file will not be much better but anyway: it can. The key here (and many many years ago) is that lossless does NOT mean file type (or high quality file type) but just describe the container which you used. They can hold anything -- poor mp3 files, decoded to WAV MP3 files (which will not become better only because they are now in Flac) and HD WAV files too... And, WAV is container too. With lossless compress-algorithm. Raw files are PCM and LPCM. ... Simple, wrong terminology makes wrong minds and just generate many problems in understanding of what's really going on...
Thanks Jmvalin, if you could give me some direction that would be much appreciated.
You want to look at the celt/celt_encoder.c file. The transient_analysis() function returns 1 when the current frame is a transient and 0 otherwise. It also computes an estimate how how "strong" the transient is, which it returns in tf_estimate. That value gets used in compute_vbr() to boost the bitrate. To change the behaviour, you'd have to change the value of that estimate, and then update tf_calibration so that the average bitrate doesn't change.
That's curious -- I assumed that when "tonality estimation" was implemented in v1.1 for tonally rich content, the final bitrate did actually increase when averaged over a large collection, compared to v1.0. Further boosting transients wouldn't work the same way?
No, when tonality estimation was added, the bitrate of the (vast majority of) non-tonal files decreased slightly to ensure that the average over a large collection stayed the same. Of course, you can argue how representative my collection is, but I try to make sure any change I make to VBR does not change the overall average. One note about 1.0 though. While it did have transient boosting in VBR mode, the VBR was tuned to always produce the same average over an individual file. Truly unconstrained VBR only arrived with 1.1.
In any case, I wasn't making the case for this boosting feature to become the default behaviour of the encoder, just that it would be useful to be able to have it as an option if needed (much like the ability to define framesize).
If a VBR change is good, if should be on by default. If it's only good in some files, then you might as well just increase the value you pass to --bitrate.