Looks like not a lot of folks concerned with burning CDs these days. I guess I shouldn't be surprised...
CD Hardware/Software / Re: EAC: Is It OK To Recreate CUE Sheets For Existing Rips Using another Drive?Last post by Mike457 -
Yesterday I conducted the same test that you did MinorKey. I obtained the same exact results for all three options as well. The only difference I saw was the time it took to read the gaps, with Secure taking longer than both Inaccurate and Accurate.
I've managed to prevent the bug from happening by removing "bHandled = FALSE" from OnLButtonUp method (PropertyList.h:605).
Doing that results in crazy buggy behaviour.
Unfortunately Monoprice have fallen from grace as far as I'm concerned. I got some of their USB-C cables, and they look great, but were so terrible at voltage dropping that I had to return them. Great customer service though, they just let me keep them instead and refunded. After that, engineers Nathan K and "USB vigilante" Benson Leung (who works at Google doing USB-C stuff) tested them properly and found the same thing, rating them very poorly.
And looking back, the Lightning cables I bought from them are also wonky, charging much slower (this was before MFi though IIRC). Their audio cables might be simpler and less prone to failure, but I just don't trust them anymore.
I used to really like Blue Jeans Cable, but I haven't bought from them in years, and they do specialize in A/V.
I want to share the trailer of my studio a mix between Sci-fi, CG animation and electronic music its not a track as itself, this is the reason I decide to share it as off-topic.
Last post by DVDdoug -
Just a few random comments -
- Ripping accuracy is different from encoder sound quality. If you can correctly read all of the bits from the disc, it doesn't matter what software you're using. Rippers that support AccurateRip will tell you if you have a perfect rip or not (if the disc is in the database), so it's best to use one that supports AccurateRip. And, CueTools can actually perfectly-correct some errors
Sometimes error hiding can work, but it's best to avoid read errors if possible. I've had a couple of discs that had audible errors but I was able to make a good-sounding digital-to-analog-to-digital recording by taking advantage of the error-hiding built-into the player software.
Sometimes data errors are not audible and sometimes they can sound very bad (ticks, clicks, skips, etc.). Sometimes I get reported errors, but I don't hear anything wrong. By now, I've forgotten which CDs were "bad".
- Most MP3 encoders are based on LAME, which is probably the best. EAC and foobar2000 will give identical results if LAME is configured identically (and assuming there are no read errors). Microsoft and Apple have their own MP3 encoders. At higher bitrates/quality settings, they will probably all sound the same and they will probably all sound identical to the uncompressed original.
- Spectrum analysis can sometimes tell you something about sound quality, but, it's a lousy way to compare lossy compression. It's easier to get a good looking spectrum than it is to get good sound, and you could tweak the settings to get a better spectrum while making the sound worse.
- If you want perfection use FLAC, and don't waste time studying spectrums. MP3 and AAC are lossy (although it can often sound perfect). FLAC is "better" than WAV because tagging (metadata) is more widely supported and the files are almost half the size of WAV.
The tag names and contents in flac and vorbis are (largely) the same but the container formatting is very different. Except that flac can be placed in an ogg container, that's very rare though and you should probably just forget I said it.
I have no idea if including more padding will help in your situation. The tagger is clearly doing something undesirable that could possibly be considered a bug. You can play with padding but a more reliable solution might be to try different software. Even just as a test, it would show that you aren't doing something completely crazy and that it is just one program that is messing up.
Just for the record, I've tagged a lot of flac and vorbis files without seeing symptoms like you describe. They aren't inherent to the tag format.
I find that pretty hard to reproduce but I do get the occasional flicker.I can consistently reproduce it though. The easiest way:
1. Open property list that is big enough to have scrollbar.
2. Click on top item to make it 'blue'.
3. Click on 'arrow down' button on scrollbar.
Result: value of first item is wrong now and matches the selected 'blue' item.
FWIW, it looks like 3rd party PropertyList library is to blame but I have no idea how to fix it.I've tried debugging a bit (lib is back from 2003, lol), but couldn't find the exact source of the problem. I've managed to prevent the bug from happening by removing "bHandled = FALSE" from OnLButtonUp method (PropertyList.h:605). But that's just brute-force programming -_-. This lib should be probably replaced some day with the more robust one (and may be a bit younger than 14 years old).
I follow advices and with the code below : this compile.
However, the output entry does not appear in FB2K output combobox.
I probably miss something, but I don't know what...
(output_asio derives from output_v2).
class output_asio_instance : public output_asio
If you are going to delete the old - and, assuming you have not already done so - I would have used a utility that deletes duplicates by name and/or by content, to see if there is anything left uncopied / unconverted.Audiotester can be very useful to find corrupted FLACs, which are too corrupted to be recognized by fb2k as FLACs, before mass conversion. Also it is multi-threaded, so much faster than foo_verifier.