sarverjoshua

I have no clue. haha I'm pretty sure it'd be illegal if I sent it to you, not to mention that my internet's capped. Try what I do though. Pick out one specific instrument, tune out the others, and do a blind listening test.

"Day Tripper" by The Beatles from the Past Masters. When I test I pick out individual characteristics instead of everything combined. Listen from start to about 8seconds (until the bass really comes in). I turned sound enhancer, sound check, and fading when I did this to get as pure a possible. I wanted to focus on the intentional static cause it's a really easy one to pick out from all the other sounds. I turned up my stereo really loud but turned down the bass so I could focus on the static. It's a difference, a little one but a difference. I know it's just static but if that's messed up than I'm thinking so is everything else. I had to blind test through the set of four about 30times before I could get it for sure but I got it 100% every time. Let me know what you get. I'm interested now.

@wgscott Yeah, I dunno. I did a blind test and I picked ALAC out every time. It's so slight though it's ridiculous that I even worry about it. I could be imagining it but the odds of picking it by chance every time during a blind test is really low.

Theoretically they're the same, and they are, but it's the VBR...which makes sense cause I know VBR anything sucks. The processing load can't be that heavy. Like I said before when I do a Handbrake encode I run all the compression stuff up (I can give my settings to you if you want). I know lossless is lossless, but ALAC seems as if the bytes are lossless but the output/audio isn't. But all the same, it's still lossless. Can you explain the resource fork to me? What I have noticed in my testing is a difference in sound *not* necessarily quality. Here's what I think of it as: A piano plays a specific song, and then a trumpet plays the exact same song. (I'm bad with music so this example might suck.) Assuming both instruments are tuned and all that stuff, the quality is the same but the sound is different. I hear a slight difference sometimes with ALAC vs. AIFF. It's not as different sounding as piano and trumpet but that's how I view it.

I get what you're saying with the compression algorithm (I'm goning to definitely look into it more) and I understand lossy/lossless. But if you look at my previous post, some bytes are still missing from the file. Unless if it's applying compression and the OS only recognizes the uncompressed size (like it does with HFS+ compression). Where are the bytes going? And why am I gettting a different sound with ALAC than AIFF? What are your thoughts? It's definitely completely lossless, ALAC, because (like I said) when I convert it back to AIFF it sounds the same as the original. It has to be with how the OS handles the file. Thanks for the info, too.

Sorry. I'll get it next time, wgscott. (I'll blame that on autocorrect.) I use afsctool, it does everything in place. If I'm not mistaken ditto makes a copy of the file and then switches them around...which afsctool probably does but I just prefer it cause it's quicker. I might have mis-taken your post but: so you couldn't see a difference between the HFS+C and the standard file? If it isn't HFS+C, then I'm set on that whole "cutting out blank bytes" idea. I'll reply to this when I can and work on it when I can: I'm still in high school. Hopefully daily if not more. Thanks for helping! EDIT That cutting the wrong blank bytes doesn't make sense. I can convert ALAC to AIFF and I can't tell a difference during blind testing. They bit rate, file size, everything is the same between the original and the converted ALAC to AIFF. It could just fill the blanks back in but it can't possibly fill in the ones it cut out containing stuff cause it's too liberal. So it has to be something else. The processor issue makes sense but I make some hard-core Handbrake encodes that use some serious processing power to decode and I notice no issue with anything...and that's video *and* audio.

@wgscoot No I haven't. I manually run a terminal command. Are you thinking the ALAC is HFS+ compressed maybe? That might make sense because I know the compressed data size is only given when looking at the root of the drive: the individual files show the uncompressed size. I could test it but my only problem is: how, if I can't see the compressed size of the individual file. If it is HFS+ that is causing this, then it's got to be another problem. I could throw the file over on a Windows computer and see (obviously it doesn't support HFS+ compression), but then again I think Windows is on the 1024 count and Mac on 1000 count for file size.

Just being a noob and OCD about my music. Why is there FLAC and WAV if there's AIFF, the format the song came in? They don't do anything other than change the format (possibly screwing up the sound). Whereas ALAC is (claimed to be) the same, just in a smaller file. This is why I'm all ALAC, until I found a discrepancy in sound. When I test I put iTunes on shuffle, turn up my stereo, flip through with my remote a few times before I begin to move stuff around, and then I begin. I event name everything the same so it adds another layer of "blind-ness", I just put info about the file in comments where I can't read it until I "get info" on it. I didn't want to hear a sound difference (saves me converting ALAC to AIFF) and I wanted to believe ALAC was the real deal but I still heard a difference. It can't be something my mind is telling me. Not to mention I can pick ALAC out of the bunch. It takes going through about 20–30times, but I was truly blind. I had no idea what it was playing. I also noticed an oddity in one of my songs. (I think it was a Bob Dylan if you're curious.) But the song was 169s (2m 49s) and the bitrate was 875kb/s, therefore basic math says my file size should have been 147,875kb but it was actually a much small 18,540kb. Something isn't working out. It's almost as if ALAC is cutting out something. I'd assumed it's cutting out blank bytes that are there only because the song isn't at the specific bit-rate; like upscaling a lossy except not at sinful. haha Maybe the algorithm is too liberal and is actually cutting out small pieces of data it thinks is blank. Theoretically if it did this, without side effects, it would still be lossless cause all bytes containing information are there.

I'm a newbie but I have to comment after reading and my results. I did some blind testing and I could pick out the ALAC every time. It took a while, and it was not always the clearest of things, but I could pick out ALAC every time. I did a blind test with ALAC, AIFF (one copied from the CD, one imported through iTunes, and one AIFF from ALAC). Surprisingly I could not distinguish between any of the AIFF's (even the one from ALAC). I was listening to the beginning of "Day Tripper" by The Beatles. The intentional static at the beginning was sharper and a different pitch in ALAC than in the AIFF's. I don't have an expensive stereo system but if I could hear the difference in a crappy one, I gotta wonder the difference is in an expensive setup. I was also surprised the ALAC to AIFF sounded as good as a pure AIFF. You can *never* "upscale" quality, so something weird has to be happening with how my Mac processes. I've got 4gb RAM, Core2Duo 2.4GHz, and Lion. I think Woodsdweller had it with his one post. Maybe the processor is taking the average amount of cycles needed to decode and is using that to play. It would been insane to have the cycles jump around just to process a song. I also think is has to be the software intentionally allowing it. If I compress a folder full of stuff (either with the HFS+ transparent or standard compress) and I uncompress it, it just doesn't uncompress the average amount of data per document in the folder. What do you guys think?