CD Hardware/Software / Re: EAC: Is It OK To Recreate CUE Sheets For Existing Rips Using another Drive?Last post by MinorKey -
Mike, thanks for posting your findings. I guess the EAC veterans already know this, but finding something out for your self is always different. I think I can be happy with my settings then.
Last post by polemon -
Is Nero aac inferior than fdk aac. Which of opus, aac(m4a) produce smallest file size for music.When it comes to file sizes, it's impossible to answer. You'd have to create a test sample, such that it is transparent for your setup, use-case, etc.
Then, you can have a look at the file size. On average, file sizes between Apple AAC and Opus seem to be similar for a stereo track. At least in my cases.
As for Nero AAC vs. Fdk AAC, here are some listening tests by other users: http://wiki.hydrogenaud.io/index.php?title=Hydrogenaudio_Listening_Tests
I'm not sure whether Nero AAC still sees maintenance, though. However, I'd simply make a short ABX test yourself if I were you, etc.
I'd give yourself a margin, when it comes to size differences, though. When the difference in file sizes is in the single digits percent wise, I'd deem them equal.
Also note, that it's down to the settings, you can actually make very large files, which sound horrible, by using a rather unfortunate combination of settings. So be wary of that, should you try to tweak them, etc.
Reproduced, thanks. Subsongs (playable_location::get_subsong) in MP4 are zero-based, when in MKV they are 1-based, so we have one chapter behind. With that said, there seems to be no reliable approach to get correct offset. But anyway, some ugly fix is doable.
UPD: removed incorrect observation.
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.
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).