Bit-transparent audio editors & DAW

[UnderTow]

Originally Posted by Dubai

thers a binary bit by bit file comparation utility in DOS.

You really have no idea what you are doing.

Here is a proper null test:



Original file was loaded into Sonar, selected and bounced out through the main bus. (So there is actually an extra step there).

Original and bounce were loaded into Sound Forge. One file was phase reverse pasted into the other using the "Mix Special" function. Result: Absolute silence. Every AUDIO bit is identical resulting in a perfect null when mixed this way. In other words Sonar did not affect the sound in any way whatsoever.

Alistair

PS:

exporting with WAVE file format gives different file size,
exporting with WAV (Microsoft) gives closer file size, but not bit by bit exactly.

You mean broadcast wave? Fancy that! Adding SMPT timestamps to the file will give a different file size. It will NOT affect the audio.Stop posting as though you understand anything in digital audio because you clearly don't.

[Dubai]

Originally Posted by UnderTow

You really have no idea what you are doing.

Here is a proper null test:

Original file was loaded into Sonar, selected and bounced out through the main bus. (So there is actually an extra step there).

Original and bounce were loaded into Sound Forge. One file was phase reverse pasted into the other using the "Mix Special" function. Result: Absolute silence. Every AUDIO bit is identical resulting in a perfect null when mixed this way. In other words Sonar did not affect the sound in any way whatsoever.

Alistair

PS:


[/U][/B]You mean broadcast wave? Fancy that! Adding SMPT timestamps to the file will give a different file size. It will NOT affect the audio.Stop posting as though you understand anything in digital audio because you clearly don't.

not broadcast wave,
Sonar can export in different formats
(WAVE, WAV Microsoft, etc...)
the most common is Microsoft WAV, developed by Microsoft, IBM. (Intel / Motorola)

¿how can they null, if the files are not bit-by-bit perfect? using Microsoft FileComparator.

[UnderTow]

Originally Posted by Dubai

¿how can they null, if the files are not bit-by-bit exactly?

Here is a perfectly clear explanation:

YouTube - illusion of superiority

Alistair

[huub]

I think it's often better to ignore certain posters, although I am now typing instead of ignoring.. ( "yes, the sound changes with version2, sounds a bit mellower, if the song is harsh ver2 midbass sound better warmer, but if the song is detailed, ver2 highs sound softened." Should give one a clue or two to ignore from now on)

Or maybe he's just f-cking with us,you never know

[UnderTow]

Originally Posted by huub

I think it's often better to ignore certain posters, although I am now typing instead of ignoring.. ( "yes, the sound changes with version2, sounds a bit mellower, if the song is harsh ver2 midbass sound better warmer, but if the song is detailed, ver2 highs sound softened." Should give one a clue or two to ignore from now on)

Or maybe he's just f-cking with us,you never know

A much more important question is: Are those barefoots in your profile pic? I'd love to hear how those boxes sound.

Alistair

[Riccardo]

Originally Posted by nkf

There was a member here called space2012, who was contaminating many discussions with a lot of randomly splattered technical mumbo jumbo.
dubai seems to be a re-incarnation after this guy was banned.
It makes no sense to discuss anything with him - this is either art with wording and technical terms or simply some self inflicted mission for whatever.
I respect the knowledge here very much and it would be sad if this get spoiled by more and more absurdity.

Doesn't seem to be, it is , banned many times, this last incarnation i still standing as a "last chance" we decided to give him. Here we have a classic in the making as he is joined by another long time acclaimed dithering expert.

[UnderTow]

Originally Posted by Riccardo

Doesn't seem to be, it is , banned many times, this last incarnation i still standing as a "last chance" we decided to give him. Here we have a classic in the making as he is joined by another long time acclaimed dithering expert.

His dither is long lasted. Might be an archiving expert too!

Alistair

[Jon Hodgson]

Originally Posted by Dubai

thers a binary bit by bit file comparation utility in DOS.

Start
cmd
cd c:\
c:\FC /b file1.wav file2.wav
c:\fc /?

¿how can they null, if the files are not bit-by-bit exactly?
not even the same file size!







if they null its because null test is not accurate.
my 999 euro please!

exporting with WAVE file format gives different file size,
exporting with WAV (Microsoft) gives closer file size, but not bit by bit exactly.

Sonar...



screen capture by Techmith Snagit Demo.
Screen Capture | Snagit | Screen capture software by TechSmith

The fc output is a dead giveaway that you're not comparing like with like. If what we were looking at there were the sample stream for the same time period then we wouldn't be hearing subtle differences, but COMPLETELY different sounds.

So major pilot error here somewhere.

[haberdasher]

Originally Posted by Dubai

the only difference possible should be signed vs. unsiged, Sonar .wav (Microsoft) only exports Signed 16-Bit PCM.

"If the sample is 16-bit signed, the sample range is from -32768 to 32767, with a centerpoint of 0.[8] (For example, signed LPCM data is used on Audio CD, DVD Video, 16-bit LPCM in WAV, audio/L16, etc.)
If the sample is 16-bit unsigned, the sample range is from 0 to 65535, with a centerpoint of 32768.[7]"

Do you understand what that part that you quoted means? That means that the PCM data is stored in a totally different way. Audio in a signed 16-bit file will have completely different numbers to the same audio in an unsigned 16-bit file, because they say the same thing in different ways. If a signed file did have the same numbers as an unsigned file, the meaning would be completely different.

I'm not sure why you're reading this and claiming that comparing representations of audio data is somehow more meaningful than comparing the audio data itself.

It's like saying "this CD looks visually more like a completely different CD by a different band than it does the U-matic master tape it was pressed from. Look how it's round, thin and shiny instead of cuboid with tape in it." It's true, but not very relevant.

[UnderTow]

Originally Posted by Jon Hodgson

The fc output is a dead giveaway that you're not comparing like with like. If what we were looking at there were the sample stream for the same time period then we wouldn't be hearing subtle differences, but COMPLETELY different sounds.

So major pilot error here somewhere.

Actually, just out of curiosity, I compared the two files in my above test (the ones that ARE bit for bit identical as far as audio is concerned) through the DOS application and it just kept spewing out data. On and on...

I am guessing it doesn't recuperate from the different header lengths. (And how would it? It is just comparing files and has no notion of the wave file structure). It is comparing bits with identical offset from the start of the files all the way through: Every data word is different due to the different header sizes. It gives a difference for the whole files from start to end. Nothing really surprising.

Actually, I bet you those files are identcial sonically which is even more interesting because it tells us alot about the posters subjecivity when listening.

Alistair

[haberdasher]

Originally Posted by UnderTow

I am guessing it doesn't recuperate from the different header lengths. (And how would it? It is just comparing files and has no notion of the wave file structure). It is comparing bits with identical offset from the start of the files all the way through: Every data word is different due to the different header sizes. It gives a difference for the whole files.

Alistair

Yeah, exactly. In the best case it's comparing two "offset" files. When it's only the header that's different it's probably possible to chop the file up in such a way that it passes this test. Pointless, but probably possible.

[24-96 Mastering]

Originally Posted by Dubai

¿how can they null, if the files are not bit-by-bit exactly?
not even the same file size!

if they null its because null test is not accurate.

I'm not quite sure yet how to react to that...

Originally Posted by Dubai

my 999 euro please!

I suggest checking your test methodology before taking me up on my bet.

[Jon Hodgson]

Originally Posted by UnderTow

Actually, just out of curiosity, I compared the two files in my above test (the ones that ARE bit for bit identical as far as audio is concerned) through the DOS application and it just kept spewing out data. On and on...

I am guessing it doesn't recuperate from the different header lengths. (And how would it? It is just comparing files and has no notion of the wave file structure). It is comparing bits with identical offset from the start of the files all the way through: Every data word is different due to the different header sizes. It gives a difference for the whole files from start to end. Nothing really surprising.

Exactly.

My point is that I can see from the data that what were looking at there is not the same point in time in two subtly different sample streams... you're either looking at two very different sample streams, or two different time points (which you would get with different header sizes as you've already deduced, and so probably the culprit here).

So I know straight away that the test is flawed.

It's like if someone was purporting to show me evidence that one word processor program introduced spelling errors while another didn't and showed me a page in english versus a page in german (or a different page in english) and said "look, they're different".

[Mark D.]

Originally Posted by PBM

A more accurate description of an object does not make the object itself any bigger. So maybe this is really meant as a remark about our perception? Cheers, Eric

Glad you picked up on that Eric. I meant how a 24 bit original playback in the DAW sounds better than when it's truncated to 16 bit, of course. The quality was what I meant to refer to. Kind of how we can sometimes perceive louder as better. Sort of the reverse I guess. The loss in what is a resulting 16 bit file is not actually 'quieter' in db of course. The 24 bit file just seems more dynamic. So louder probably wasn't the right word, I'll chose better next time. I hope this post doesn't start a hair-splitting contest over 24 bit vs. 16 bit. I think we agree, 24 bit sounds better. Back to our regularly scheduled program.

Originally Posted by Dubai

¿how can they null, if the files are not bit-by-bit perfect? using Microsoft FileComparator.

The difference is so small. Did it ever occur to you that your having that additional character (Jov2 intead of just Jov), or even different time & date stamps, or, perhaps it is some slight overlooked variance in what you bounced (which is inaudable) caused 'Jov2' to be larger than just 'Jov'? That is such a slight difference in size. Even how Windows writes to disk probably isn't that bit perfect. Who knows what slight variance is there from write to write. The true test is audio, the above test shows they null. It proves Sonar has no audible difference. You have not been able to prove any actual audible differences in Sonar.

[dcollins]

Originally Posted by Mark D.

Even how Windows writes to disk probably isn't that bit perfect. Who knows what slight variance is there from write to write.

No. There are layers of error correction to ensure that reads and writes are bit accurate.

A single misread bit can cause your computer to crash, you know..........

I think you are making far more of this than need be.


DC

[Thor]

If there was a slight variance from write to write, you would find Word documents with magically appearing spelling errors, and Excel spreadsheets where numerical values changed all by themselves.

Oh, wait a minute....




Thor

[narcoman]

Originally Posted by Dubai

not broadcast wave,
Sonar can export in different formats
(WAVE, WAV Microsoft, etc...)
the most common is Microsoft WAV, developed by Microsoft, IBM. (Intel / Motorola)

¿how can they null, if the files are not bit-by-bit perfect? using Microsoft FileComparator.

.... there is LOADS of information in the WAV format that will not be the same even the though Audio might be. You can't use FileComparator to check whether audio content is the same. Different headers, timestamp information and myriad other WAV format things will ensure you'll never get any WAVs (apart from the exact same ones) to bit for bit compare. You need to do audio comparisons with that in mind.

[narcoman]

Originally Posted by Dubai

Bit-transparent audio editors & DAW
if its 100% Bit transparent must be 100% exactly the same file bit by bit when exported.
anyway.. headers should be same size, and audio data should be identical, but it does not.

there you go.... header information FOR A START will be different!!

[Jon Hodgson]

Originally Posted by Dubai

Bit-transparent audio editors & DAW
if its 100% Bit transparent must be 100% exactly the same file bit by bit when exported.
anyway.. headers should be same size, and audio data should be identical, but it does not.

People have already correctly informed you about the metadata in wav files, but approaching the question from a slightly different angle...

The wav format stores audio in uncompressed form, so x seconds of audio will always take up exactly the same amount of space. The fact that you have different file sizes tells you one of two things... either you have different amounts of audio, or there is different metadata. So, either you're screwing up your exports, or your theory that the metadata should be indentical (in size at least) is incorrect... so once again you merely prove your test methodology is incorrect.

[Mark D.]

DCollins and Thor, I did generalize a bit, but my salient point was Sonar has no audible difference
between imported/exported files vs. an original. I don't know if a different name or time and date
stamp will affect some measurement. I said it was a possibility. Like the above, I also believe the
differences were caused by what he did in the file export. I am not "making a big deal of this" I'm
just responding. If the possibility I put out was incorrect, that's fine. Let's get back to the topic.

[Teddy Ray]

dont know if it is relevant, but I use the WASAPI output in Foobar.

WASAPI is a new audio output method introduced in Windows Vista; among other things, it provides an exclusive mode that allows applications to take full control over soundcard's resources [B](muting any sounds played by other applications) and play unaltered bitstream without passing it through the Windows mixer.[/B]

definitely an improvement not going through the Windows Mixer..(WMP does not bypass it)

[Audiop]

Originally Posted by Dubai

this is how it looks real jitter... with the same Saw wave arround 6KHz.

***

different clocks, same converters. (test done 2 times to confirm results)
Drawmer M-Clock vs. RME SteadyClock(TM)
external (DDS Disabled.) vs. internal.

(that test was done usign a software generated saw wave = 0 jitter, and recorded: DA-->AD)

As have been pointed out recently (and also way back when you posted as Space 2012) those pic's have nothing to do with jitter. Still you refuse to listen and be a part of a meaningful constructive discussion.


Jitter means random noise and/or intermodulation distortion added to the signal.

Your sawtooth test only shows that the timing of the clock to when you press "go" is different. I told you about this a couple of days ago and asked you to read up on brickwall filters and Gibbs phenomenon.

If you feed a non lowpassed transient signal such as a step response, square, triangle or sawtooth you will see slightly different placement of the "ripple" on the same gear without changing anything at all repeating the test. This goes for a system with 100% perfect time precision as well IOW a system totally free from jitter.

Also generating a sawtooth or squarewave in the puter typically means high frequencies not allowed because they are at and above the nyquist frequency of the sampling system.

If you want to learn, try to run a short series of tests on the same converter without changing anything and compare the resulting waveforms. Also try to use a lowpassed signal and see how the results becomes identical.

Do this if you want to gain some credibility and bring something useful to the discussion.


/Peter

[narcoman]

Originally Posted by Audiop

Also generating a sawtooth or squarewave in the puter typically means high frequencies not allowed because they are at and above the nyquist frequency of the sampling system.

r

...and not reproducable by any speaker system ..... infinite energy anyone?

[Audiop]

Yes please!


/Peter

[omasciarotte]

Originally Posted by narcoman

there you go.... header information FOR A START will be different!!

Sorry to pick nits but, metadata is not essence and it's the essence, or data "payload," that determines "bit perfectness." Yes, the header can contain incorrect metadata, like a bogus sample rate or emphasis flag, but that would be caused by either a bug or operator error and should not be part of the discussion.

[Cheebs Goat]

Looks like a lot of people are barking up the wrong tree.
Comparing files will get you no where. The issue isn't necessarily "does the software produce a bit accurate file?". These sort of things are usually matters of what happens to the data on the way to the sound card/interface.

*The file plays.
*numbers start flowing to the D/A
*Oops! This D/A only deals with 48 khz!
*Conversion happens
*No longer bit perfect.

The file itself didn't change. There is no evidence anywhere of the conversion. But what you heard was not bit perfect. And that is all that matters when making audio decisions.

Any number of things could happen:

Windows mixer is not set to 100% -> Volume calculation -> not bit perfect

I'm not up on the specifics of these things and I don't know where exactly to look... but then I don't do audio work on a computer, either. All I know is that it is not an issue of the file itself being altered. The sound is altered on the fly en-route to the D/A converter.

Think of a graphic sent to an LCD monitor running at lower-than-native resolution. The graphic file itself remains bit-perfect and any file comparison utility would confirm that, but the monitor that to re-interpret everything to fill 1600x1200 physical pixels with 1280x1024 pixels worth of information. You are not seeing a bit-perfect picture even though the file is bit-perfect.

[omasciarotte]

Originally Posted by Cheebs Goat

Looks like a lot of people are barking up the wrong tree.
Comparing files will get you no where. The issue isn't necessarily "does the software produce a bit accurate file?". These sort of things are usually matters of what happens to the data on the way to the sound card/interface.

Comparing files is a good secondary step after you performed a null test and find that files do not null.

Originally Posted by Cheebs Goat

I'm not up on the specifics of these things and I don't know where exactly to look... but then I don't do audio work on a computer, either. All I know is that it is not an issue of the file itself being altered. The sound is altered on the fly en-route to the D/A converter.

The standard first test of bit perfectness is to capture or bounce some reference material through the device/chain under test, then open that file, invert polarity, sum with the original, and inspect the residual.