 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
75.215.176.195
Doing some preliminary comparisons on the laptop, I burned a CD with "identical" tracks, where one was ripped non-compressed and the other was compressed with FLAC lossless codec (at it's highest-rez setting). And there is a definite difference between the tracks- The FLAC track is somewhat "vague" with time information. A little "dull." A slight loss of transparency. The music didn't "swing" quite as much.But now the kicker. I did a file comparison of the .wav files I used prior to burning, using EAC, and from a data standpoint, the non-compressed .wav and the FLAC encoded/decoded .wav were identical!! So in the case of FLAC, from a data standpoint, it is truly lossless.
I think there's something going awry from a jitter standpoint. That's my hunch for now.
I will do the ABX test using my main PC at home in a few weeks, where the hardware is more-ideal for handling CDs and CD-Rs.
Follow Ups:
It appears that you are doing your listening test on a computer using Winamp. So why are you creating an audio CD? Why don't you just listen to the wav files directly via Winamp. This will remove a lot of extra variables from the issue. Maybe it is just the order the tracks are written on the CD is the culprit. Write another CD with the tracks reversed. Your opinion may change. Also try another with the same wav file on two different tracks. I suspect that you will still feel that one track sounds better than the other.
I want to do this on my home rig. A good home CD playback system is still more-resolute than a good PC-based system. Although the new Winamp 5.34 closes the gap somewhat. (The biggest problem I have is the playback cards are non-oversampling on the PC. Where it's time-resolute filtered on the home rigs. They handle complex passages better.I want to set up this test on speakers as well. I am unable to discern absolute polarity with headphones, and I don't want to do any trials with inverted material.
I'd also like to make this available to those who first request it. Especially if I do attain a positive ABX correlation. (I might also do an "AB" disc where one merely chooses the track he thinks sounds better.) The main thing is they can see for themselves that the files are identical.
And finally, since lossless is often used in PC-based replication, it would potentially throw water on the notion that lossless means harmless, in regard to the integrity of the audio signal. And its possible audible effect can be transferred to CD-R.
Ok it makes more sense now. But as I suggested, write another CD with the tracks reversed and compare. You may notice a difference.
Also I usually do such testings on re-writable medium so no money is wasted or the environment is not harmed.
I want to do this on my home rig. A good home CD playback system is still more-resolute than a good PC-based systemHey todd, what are you using for a pc based system? Is the pc optimized for audio, etc.
My experience has been just the opposite. My trans/dac combo was no match for my pc.
"Hey todd, what are you using for a pc based system? Is the pc optimized for audio, etc."Well, I have both a laptop and a regular PC.... And everybody has a different idea of what constitutes an "optimized" system.....
It sounds decent.... A lot better than what I initially had.... I'll never mistake it for a Prism DA-2, however....
I personally think PCs are compromised because the nature of Pentium and other high-power processors just puts too much RFI into the mix....
Are you going from the pc to a dac, or are you using a sound card?If so, what are you using?
Interesting that you talk about RFi. I chose a slow via machine for the fact that it was slow and supposedly produced less RF.
Yet others will say that faster PCs sound better.
All I know is that the pc system is better than my not to shabby trans dac combo. BUt the thing wasn't cheap and was actually a bit more expensive than the hifi rig. But I did go for the flashy wireless touch screen, etc.
I really hope you are not using onboard audio...that can't sound good.
After reading through all the posts, the first thing to cross my mind hasn't been mentioned yet . . .It would be interesting to see if some of the software/hardware you guys are using is inverting the polarity of the file or not. I'm not talking about phase, I'm talking about truly inverting the entire signal. This will make a bigger difference between two different versions of the same recording than you think. A lot of people won't notice it until they hear the music come out of their speakers the correct polarity, and a lot of people also will not notice it because most commercially available CD players invert.
Supposedly, a lot of computers invert as well. I've read that my PowerMac G5 inverts, but I'm not sure if the author was referring to the sound output, or CDs burned on the drive. I'm guessing sound out was what he meant, because most CDs I've burned in iTunes seem to be correct polarity, because I have to use the "invert" switch on my preamp. If the previous sentence doesn't make sense, it's because I know my CD player inverts. So, correct polarity CD in the player (an NAD 5000), is inverted going into the preamp (a Parasound P/LD 1500), and the preamp is capable of inverting the signal, so what comes out of the speakers is correct.
What difference does it make? Timbres are a LOT more correct, timing is generally a lot better, and it seems like there is at least an extra octave of bass extension. If an inverted signal is coming out of the speakers, it will be more noticable in lower-pitched sounds.
If your preamp won't allow you invert signals, you can always play with connecting your speaker wires "backwards" to find out what is going on with your system.
BT
"It would be interesting to see if some of the software/hardware you guys are using is inverting the polarity of the file or not. I'm not talking about phase, I'm talking about truly inverting the entire signal."I'd think two files coming up as identical via EAC's File Compare utility would eliminate such possibility.
I'm not sure, haven't studied that end of things enough to know if a digitized signal accounts for polarity or not when it is encoded, or if it only deals with frequency and amplitude when digitized.The reason I say this is, you would think that most makers of mid-to-high end audio gear would know enough to build a CD player that doesn't invert, but I can't think of one in the $300-$800 range I've heard that DIDN'T invert.
Perhaps it is a resolution issue when sampling a 16-bit file, or which of the 16-bits it is using to sample, etc.
or maybe I'm just crazy . . .
. . . one or two the little voices in the back of my head assure me that I am not, so I just ignore the other 7 . . .
BT
You burned the exact same WAV file to two redbook CDs and you think they sound different. Right. Actually, after having read the dozens (hundreds?) of similar claims in your past posts, I have absolutely zero doubt that you think you hear a difference.The next thing you'll be telling us (or yourself) is that you hear a differerence between identical WAV files that you receive as attachments in two different email programs.
"You burned the exact same WAV file to two redbook CDs"It's actually burned to the *same* CD.... One was ripped directly to .wav, the other was ripped encoded via FLAC and decoded via FLAC to .wav. This was done within dBPowerAmp, for both .wav files.
"Right. Actually, after having read the dozens (hundreds?) of similar claims in your past posts, I have absolutely zero doubt that you think you hear a difference."
This is why I want to back this with a DBT/ABX test. The data itself may be the same, but the way the files are stored is what makes them different. I want to find out if this would bear out in an objective test.
I was playing the files from the hard disk. I assumed that it was caused by some "strain" upon my old laptop during decompression because when I wrote a WAV file from the WMAL file, the two WAVs then sounded the same.Rick
So you have 2 identical data files and when you burn them, you get different results.My suspicion would be that any differences are occurring in the burning process itself rather than some difference in the data files.
Or, maybe due to random chance, one of the files is more fragmented than the other and perhaps this causes some timing differences in the burn.
I really think you ought to be considering other variables here beyond the FLAC vs. lossless generation of the files. There are lots of other things that could be happening.
the FLAC copy is a smaller footprint, compressed version of the source WAV file. Just like a zipped copy of a data file. While they are fully equivalent when uncompressed, the challenge is that the decompression or "unzipping" of the FLAC variation must be done on-the-fly in real time.rw
The description above implied, if not said, that the FLAC file had been decompressed into a WAV. This WAV was bit-for-bit identical with the WAV that came directly from the CD rip. The burns of the 2 bit identical WAV files were said to sound different. Thus, no on-the-fly decompression is involved.
I burned a CD with "identical" tracks, where one was ripped non-compressed and the other was compressed with FLAC...rw
Further down it states:"I did a file comparison of the .wav files I used prior to burning, using EAC, and from a data standpoint, the non-compressed .wav and the FLAC encoded/decoded .wav were identical!!"
I interpret this as burning 2 identical WAV files, one of which was a decompressed FLAC, the other straight rip from the CD. This interpretation was the basis for my comment.
"I interpret this as burning 2 identical WAV files, one of which was a decompressed FLAC, the other straight rip from the CD. This interpretation was the basis for my comment."This is the case. The files, from a *data* comparison with EAC, were identical. But the straight .wav sounded better than the FLAC compressed/decompressed .wav. And this is the comparison I'm going to run with the ABX, with these so-called "identical tracks" burned to CD-R.
I missed the boat.rw
Rip two separate files in WAV format and compare those. It could be that any changes you are noticing have nothing at all to do with FLAC (that would be my expectation by the way). Have fun and please report your results.
Just listen to the two bit-identical files you've already got a few more times. Yes, it could be that the conditions of play one at one time and the other at another time could cause differences due to computer response. But over a number of plays the computer factors should even out.Better yet, arrange a double-blind listening session.
Since the files are noting but bits on a hard drive, and since they are precisely identical, a reasonable person would suppose they cannot sound different of playback conditions are the same.
Bill Bailey
___________________________________________
See my stereo config
For all I know, the jitter could be affected by different things running in the background, processor temperature, etc. .....
I guess it depends on whether you follow the first or the second part verbatim where there seems to be some conceptual conflict.rw
The reproduction of music is as much about the delivery of the data as the data itself. I hope we can begin with the assumption that the compressed signal of the lossless formats can be reconstructed completely bit for bit.It would seem that any cost reduction benefits from compressing the signal are negated by the added resources required, however, to deliver an identical data stream . Windows offers lossless compression of your data drives. The compromise is the same - increased capacity vs. lowered transfer rate. For those who may disagree, try it on your own computer.
rw
E,I have to agree with you. With hard drives being so cheap these days, I am not certain lossless makes that much sense. Although tagging is pretty cool.
"I have to agree with you. With hard drives being so cheap these days, I am not certain lossless makes that much sense."To one who's never really critiqued the sonic qualities of equipment, it's merely value-added. Same goes for the ones who like the synthesized music that would obscure any sonic differences.
Neither is perfect but from the reviews I have read, FLAC audio quality is preferred over Apple Lossless.
Both are lossless. Any differences in the sound of one format over the other is due to the player or the platform.
Tom was comparing the WAV to the FLAC, not to the WAV created from the FLAC. Were the latter the case he would hear no difference, (unless he imagined it).
Bill Bailey
___________________________________________
See my stereo config
blind testing. I've been going down the same path, comparing .wav, Flac, and WMA lossless files by ear, and most of the time I can convince myself one sounds "better." That is, until I blind myself.The real test for you is going to be not the ABX function, but somebody else switching the tracks while you blindly test your preferences.
And yes, I also tested .wav, Flac, WMA lossless files and they ARE bit-perfect, down to the last single bit.
FYI- I told the person who will do the ABX testing to do the following:- The order of A and B decided by coin flip.
- X decided by coin flip. (Make it truly random.)
- The possibility of "trick" trials, where A, B, and X are either from the very same track or from totally different tracks. This is to "keep me honest." (No disclosure of whether such trials are included.)
- I will never know the track facts personally. I'll just be told "Y trials I chose correctly, Z trials I chose wrong." So if I try this again, I'll still be "in the dark."
I'm not sure what you mean by "ABX testing," but Foobar player's "ABX test" function is pretty bad, and I am not sure other software players' similar functions are any better.Basically, choosing the ABX function changes the sound. Both tracks being compared become louder in volume and less transparent.
But if you mean "ABX" testing as in good old A-B testing by hand, by all means, go for it.
It's the latter case. I will create the "A" and "B" tracks, and make sure they're identical from a data standpoint. (This would prevent "cheating" by looking at the data.) Then someone else will drag and drop the A, B, and X tracks to be burned to CD. Pretty simple actually.
Hey Jon,I may have been the one to turn Todd onto this in Foobar.
I haven't heard of the isues on this, but, even if they do exist as you say, the ABX may still be a way to get a good idea if there are actual differences.
At least, I have been able to ABX "transparent" mp3s vs the original using this function...and there are a few engineer types that don't think that is possible.
Maybe it is not perfect, but it might be an easy test short of a more rigorous ABX test.
You may have turned me onto ABX on Foobar, but Foobar never impressed me as an audio player. Kind of "dark" sounding. Had a tendency to lock up too. Winamp won out, and it's worked very well for me.
Yeah Todd, I have heard from others that Winamp is better sounding.Foobar takes some work to get it to sound good, but it can sound really good.
Winamp is just slow, but does sound good, and is easier to get going right out of the box.
The 09 version of Foobar is very stable on my rig.
All this does kind of show that there is more to it than having identical files.
I have Winamp running through Windows Kernel Streaming. The volume slider doesn't even function on the player. I also have it tied to FFDSHOW for video playback, using H264 codec, and compared to the likes PowerDVD and WinDVD, it looks like HDTV.... The only drawback is you need to run the .vob files individually, which means interruptions in the playback. But the video and audio quality more than makes up for that.The big problem with Winamp is getting the "merits" (priorities) for the various codec modes right in the PC. Sometimes when I run a new utility, this messes up Winamp. The fix for this is running a utility called Gspot, where you can adjust the "merits" so each application you choose runs like a champ.
Note I don't have problems with Winamp running "slow", on my lowly Celeron-based laptop.
You like the sonics of Winamp over Zoom?I wouldn't mind using Winamp b/c it does sound pretty good, but I can't solve these 2 issues with it.
1. The playlists won't display the entire song tag. It'll only show me artist and title (no album).
2. Foobar's playlists all hang out as tabs on top, and when I click one, the playlist is there instantaneously. Winamp takes some time to load a playlist, and no easy tabbed system.
The Zoom player is "forgiving".... It will make bad transfers sound "decent", but good transfers sound a little "boring." (Zoom does not sound much different from Foobar.) Winamp is the one player that really reveals the flaws of the data transfer. It's almost like listening to good studio monitors at the mixing board. CD-Rs through Winamp best correlates to what I hear playing them in non-PC-based systems. Particularly rigs of superior sonic performance.
d
nt
Best Regards,
Chris redmond.
d
Tom compared the WAV to the FLAC file. He wasn't comparing the WAV to the WAV created from the FLAC; these are the two that were identical. Had he compared the latter two they would have sounded the same, of course.
Bill Bailey
___________________________________________
See my stereo config
"Tom compared the WAV to the FLAC file. He wasn't comparing the WAV to the WAV created from the FLAC; these are the two that were identical. Had he compared the latter two they would have sounded the same, of course."I ultimately listened to two identical .wav files, one ripped straight to .wav, the other encoded with FLAC (highest quality setting) and then decoded back to .wav, and burned as successive tracks on CD. EAC indicated the .wav files were identical, but the straight .was to me sounded demonstrably better than the one that went through the encode/decode process.
This is why I'm doing the DBT/ABX test. I want to make sure it's not a placebo effect or some psychological element here. Time will tell.
I understood you to say that you did and that they were identical. If so it is very, very hard to say that differences were anything but your imagination.
Bill Bailey
___________________________________________
See my stereo config
Maybe the decoding software has something to do with it. I would suggest to repeat the test using Foobar, set up to work in kernel mode.
you stated that you burned CD-R's with the tracks. Maybe if you burnt the track coming from the FLAC making the conversion "on the fly" it could explain the differences. Otherwise being identical files, it's hard to explain.
I was playing the files with Winamp. I will say that playing the FLAC files decoded back to .wav sounded better than playing the FLAC files directly.
Check this post out, Todd.
.... I'd call the "dirty little secret" of active DSP conversion and lossless compression.I personally wish there was some sort of protocol that transfers data from optical discs to HDD data files with as little processing as possible. Supposedly .aiff files are better than .wav in this regard. There is another conversion process called disc description protocol (DDP), which is supposedly the closest to the .cda format on the CD. The problem is a company called Sonic Studio has rights to the technology, and products that utilize it are super expensive. (Sonic Studio only makes software for Macintosh OS, so one would need a Mac in order to try it.)
> There is another conversion process called disc description protocol
> (DDP), which is supposedly the closest to the .cda format on the CD.
> The problem is a company called Sonic Studio has rights to the
> technology, and products that utilize it are super expensive.
I use Sonic PMCD to master Stereophile recordings. The audio data in
a DDP file set are identical both to those on the CD and in the
original AIF file. The advantage is that the CD data can be sent to
the plant on a CD-R, and are therefore immune to disc reading
problems. They can also be check-summed so that the plant knows if
there is an error or not.
John Atkinson
Editor, Stereophile
v
I meant as immune to any other data CD-R, as opposed to an audio CD,
which has significantly less powerful error correction.
CD plants can and do cut glass masters from an audio CD, but any
partially corrected or interpolated errors on playback become part of
the audio data on the master. By contrast, sending the plant a DDP file
set on a CD-R ensures that the audio data on the pressed CD are
identical to those in the master file.
John Atkinson
Editor, Stereophile
"CD plants can and do cut glass masters from an audio CD, but any partially corrected or interpolated errors on playback become part of the audio data on the master. By contrast, sending the plant a DDP file set on a CD-R ensures that the audio data on the pressed CD are identical to those in the master file."If data files stored on a data CD-R are more-immune to errors than audio tracks on an audio CD-R, what do DDP files have over .wav files, .aiff files, lossless-compressed (FLAC) files, or image files, stored as *data* on CD-R? (The .wav files on the CD seen on a computer in the actual .wav data format, as opposed to audio tracks in their ".cda" representation. Unplayable on a CD player.)
> If data files stored on a data CD-R are more-immune to errors than
> audio tracks on an audio CD-R, what do DDP files have over .wav files,
> .aiff files, lossless-compressed (FLAC) files, or image files, stored
> as *data* on CD-R?
The DDP file set is an image of the audio CD from which the glass master
can be cut directly.
John Atkinson
Editor, Stereophile
c
"The audio data in a DDP file set are identical both to those on the CD and in the original AIF file. The advantage is that the CD data can be sent to the plant on a CD-R, and are therefore immune to disc reading problems."This may be very true, but misses the point....
The data I've been dealing with is apparently all identical, be it straight .cda to .wav, straight .cda to .aif, or conversion via FLAC or Monkey's Audio encode/decode. The problem all-along has been the intrinsic jitter associated with both data storage and data conversion. It may be the biggest problem (aside from RFI) in regard to getting decent digital audio playback.
The DDP format is also supposedly the closest to the native .cda format, where the least-strained conversion would likely induce less jitter upon conversion during the burning of CDs.
Thank you for that piece of info, saved me alot of time.
Hi Todd, I will try this out and post my findings as I have a Mac.
"Hi Todd, I will try this out and post my findings as I have a Mac."This would be appreciated. If it indeed produces a CD or playback file of superior sonic quality, I may eventually go that way.
I hope you realise that PCs specifically and computers generally perform their various operations using a concept called timeslicing, therefore the processor is rarely (except in exceptional scenarios) dedicating all system resources to a single tasks, timeslicing introduces latency into the system, which will invariably affect performance. Consequently, the results that you are obtaining may have absolutely nothing to do with files perse and more to do with how efficiently the PC is time-slicing the various processes, jitter indeed but not as you know it.
Music making the painting, recording it the photograph
And it's been true in my listening that faster processors sound better.
This is why I want to try this on my more-powerful home PC.I might ultimately try something *really* powerful, where the .wav files would be stored on a dedicated hard drive. And maybe use multiple power supplies, where the audio data handling is isolated from the core processor. Running Linux or Mac is also a possibility.
It could be the Windows, with all of its extraneous activity, could be the problem.
have you optimized the run priority of all the active threads on your computer? If not, you can effectively take that issue out of the mix. While you cannot set the "nice" value upon running of a program like on Unix/Linux systems, you can change them once they are in core.1. Get your FLAC processor running, but not actively ripping.
2. CTRL-ALT-DEL
3. Choose "Processes" tab
4. Click "CPU" twice to sort table in descending value by active process
5. Identify the couple of non-zero activity processes (except for taskmgr.exe and "System Idle Process")
6. Right click the other process(es)
7. Set Priority--> Low
8. Right click the FLAC process
9. Set Priority--> Real time
10. Exit task managerTry again. Unless you have a dog slow computer, I'm not convinced this will help, but it will mean your system devotes its resources to the FLAC process.
rw
FactorsSo don't compile a large program, process video or other intensive tasks while burning! While anti-virus and other resident background tasks exist, they consume virtually no real power. That's easy to confirm. Run task manager and sort the CPU column in descending order.
I figured out long ago that burning standalone at the slowest rate was the optimum way to rip and burn music. I also burn at 4X like Todd.
Guess again.
rw
At least Todd's response is more reasonable than yours, read it for context. You refer to yourself as a 'software engineer' yet the subtleties of timeslicing on audio playback performance (in the context of a general purpose PC) are lost on you. It reassuring that a lot of the other posters did not respond with a dim-witted post like yours.
Music making the painting, recording it the photograph
you can view all the active threads that may be sliced and their exact cpu usage using Win task manager. In real time. Unless you're deliberately running some resource hog, little is going on.Faster is certainly better, but I think the issue goes beyond mere multi threaded operating systems.
rw
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
