[Tobiah]

I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with
regard to .wav files. Almost every .wav file
that you come across has the format information
crammed into the first 44 bytes of the file.
This is a strong convention, but is not part
of the original spec. A compliant reader is
supposed to read each 'chunk', find it's size,
and move on from there, skipping unidentified
chunk names. It's legal to put some of this
information at the end of the file, which
explains the occasional burst of white noise
that you might find at the end of a .wav file,
usually after copyright information has been
added to the end.

This fact is rendering most of my soundfile
players incapable of reading the .bcw files.
The first chunk after the RIFF is the new
'bext' chunk that should be skipped by
software, but largely is not, and random
bytes inside the bext chunk are being used
as sample rate and bitwidth data.

I'm using Linux, and found that audacity
will read the files fine, but it converts
to normalized floats (values between 0 and 1),
which I'm guessing will slightly alter my
file due to rounding errors. Not a huge
problem, but it bugs me.

Toby

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Crowley]

"Tobiah" wrote ...
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

"BWF" is just a "WAV" file with one or more extra data chunks.
http://en.wikipedia.org/wiki/BWF
Compatible with any properly written application software.

I've known for a long time that 90% of the
soundfile players out there are broken with
regard to .wav files.

Are you refering exclusively to Linux applications?
Otherwise it seems like hyperbole if you were writing
about Windows or Mac apps.

Almost every .wav file
that you come across has the format information
crammed into the first 44 bytes of the file.
This is a strong convention, but is not part
of the original spec.

Of course it is part of the original spec. The original spec
allows chunks to be placed in any order. Microsoft uses
the convention of putting the INFO chunk first to make it
easier to scan (and display for the user) information about
the contents of the file.

A compliant reader is
supposed to read each 'chunk', find it's size,
and move on from there, skipping unidentified
chunk names. It's legal to put some of this
information at the end of the file, which
explains the occasional burst of white noise
that you might find at the end of a .wav file,
usually after copyright information has been
added to the end.

Caused by software which is not compliant with the spec.

This fact is rendering most of my soundfile
players incapable of reading the .bcw files.

So use "soundfile players" that are written properly.
Or live with the problem.

The first chunk after the RIFF is the new
'bext' chunk that should be skipped by
software, but largely is not, and random
bytes inside the bext chunk are being used
as sample rate and bitwidth data.

Then perhaps the files themselves aren't compliant with
the RIFF meta-format?
http://en.wikipedia.org/wiki/Resourc...ge_File_Format

I'm using Linux,

It is surprising to me that your (presumably open-source?)
applications are so poorly compliant with the standards.
Why has nobody come along and fixed these problems?
It seems quite easy to accomodate the data chunk scheme.

[Geoff]

Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with


A bunch of semi-facts and outright wrongths. Was there a question or just
expressing yourself ?


geoff

[Scott Dorsey]

Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with

I regularly use Broadcast WAV formats and have never had a problem with
anything reading them, including Audacity. Even my old Sonic workstation
which predates the Broadcast WAV standard by many years works fine.

Do an od -h on the headers and tell me what you see. You really only care
about the first 56 bytes. Compare them with the standard and also with
the header of a .wav file that DOES work for you.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Tobiah]

Richard Crowley wrote:
"Tobiah" wrote ...
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

"BWF" is just a "WAV" file with one or more extra data chunks.

I know what it is. I expressed what you said later
in my message.

I've known for a long time that 90% of the
soundfile players out there are broken with
regard to .wav files.

Are you refering exclusively to Linux applications?

Yep. I'm sure that commercial apps get it right.


Almost every .wav file
that you come across has the format information
crammed into the first 44 bytes of the file.
This is a strong convention, but is not part
of the original spec.

Of course it is part of the original spec.

What I'm saying, is that although almost every
..wav file out there has the contiguous 44 byte header,
the spec does not mandate this. As you say, the
chunks can be in any order.



A compliant reader is
supposed to read each 'chunk', find it's size,
and move on from there, skipping unidentified
chunk names. It's legal to put some of this
information at the end of the file, which
explains the occasional burst of white noise
that you might find at the end of a .wav file,
usually after copyright information has been
added to the end.

Caused by software which is not compliant with the spec.

Absolutely.

This fact is rendering most of my soundfile
players incapable of reading the .bcw files.

So use "soundfile players" that are written properly.
Or live with the problem.

Thanks for the empathy. Open source software is
usually quite good, but this particular misunderstanding
about .wav files seems to be rife in linux players.

The first chunk after the RIFF is the new
'bext' chunk that should be skipped by
software, but largely is not, and random
bytes inside the bext chunk are being used
as sample rate and bitwidth data.

Then perhaps the files themselves aren't compliant with
the RIFF meta-format?
http://en.wikipedia.org/wiki/Resourc...ge_File_Format

Sorry, I meant the first chunk after the RIFF chunk.

I'm using Linux,

It is surprising to me that your (presumably open-source?)
applications are so poorly compliant with the standards.
Why has nobody come along and fixed these problems?
It seems quite easy to accomodate the data chunk scheme.

Yeah, it's surprising.


--
Posted via a free Usenet account from http://www.teranews.com

[Tobiah]

Geoff wrote:
Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with


A bunch of semi-facts and outright wrongths.

It's fun to be dismissive. What do you disagree with?
I should have said 90% of Linux players, but then I
did mention that I was using Linux.

Was there a question or just
expressing yourself ?

Aren't news groups a valid forum for self expression?

--
Posted via a free Usenet account from http://www.teranews.com

[Tobiah]

Scott Dorsey wrote:
Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with

I regularly use Broadcast WAV formats and have never had a problem with
anything reading them, including Audacity.

Actually, Audacity read the files correctly. I was just unhappy
with the fact that it forced me to convert to normalized floats,
which would likely change the sample data to a small degree.
Ardour reads the files correctly too, but it is too complex
for simple file conversion.


Do an od -h on the headers and tell me what you see. You really only care
about the first 56 bytes.

That's part of the misconception that I was talking about.
There is nothing in the spec that says that the format
chunk has to be anywhere near the beginning of the file.


--
Posted via a free Usenet account from http://www.teranews.com

[Scott Dorsey]

Tobiah wrote:
Scott Dorsey wrote:
Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with

I regularly use Broadcast WAV formats and have never had a problem with
anything reading them, including Audacity.

Actually, Audacity read the files correctly. I was just unhappy
with the fact that it forced me to convert to normalized floats,
which would likely change the sample data to a small degree.
Ardour reads the files correctly too, but it is too complex
for simple file conversion.

Converting to floats and back is pretty much a non-issue. Load it, save
it, and do a diff on the file.

Do an od -h on the headers and tell me what you see. You really only care
about the first 56 bytes.

That's part of the misconception that I was talking about.
There is nothing in the spec that says that the format
chunk has to be anywhere near the beginning of the file.

No, but the HEADER has to start at position zero, starting with the magic
number and then with sample rate data and then the absolute address of
the first byte of the data.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Tobiah]

No, but the HEADER has to start at position zero, starting with the magic
number and then with sample rate data and then the absolute address of
the first byte of the data.
--scott

The RIFF chunk has to start at zero, but the sample rate is
in the format chunk, which usually follows, but doesn't have
to.


--
Posted via a free Usenet account from http://www.teranews.com

[Geoff]

Scott Dorsey wrote:
Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with

I regularly use Broadcast WAV formats and have never had a problem
with anything reading them, including Audacity. Even my old Sonic
workstation which predates the Broadcast WAV standard by many years
works fine.


Do they load up OK on your Teletype terminal ?

;-)

geoff

[Geoff]

Tobiah wrote:

It's fun to be dismissive. What do you disagree with?
I should have said 90% of Linux players, but then I
did mention that I was using Linux.

Assumed you meant 90% of all soundfile players. Do you use Linux exclusively
? Given that 90% of Linux soundfile players seem broken wrt BWF BWF, maybe
time to reconsider !

Was there a question or just
expressing yourself ?

Aren't news groups a valid forum for self expression?

Yep, just wondered.


geoff

[Scott Dorsey]

Geoff wrote:
Scott Dorsey wrote:
Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with

I regularly use Broadcast WAV formats and have never had a problem
with anything reading them, including Audacity. Even my old Sonic
workstation which predates the Broadcast WAV standard by many years
works fine.

Do they load up OK on your Teletype terminal ?

Hey, the Sonic has a 68000 host processor with a NuBus-based DSP unit.
It's high tech, man.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Tobiah]

Do you use Linux exclusively
? Given that 90% of Linux soundfile players seem broken wrt BWF BWF, maybe
time to reconsider !

Yeah, I don't even have a Windows box available right now.
This is a rather anomalous bug that was left unaddressed because
no one was having a problem playing their .wav files. The BWF has
exposed this incompatibility with the format spec, and the authors will
likely be responsive. A great many Linux audio programs use a
library called 'libsndfile' to access audio files of various formats,
and the author is aware of the BWF shortcoming. When he gets around
to fixing his library, a great many audio players will be repaired.


Aren't news groups a valid forum for self expression?

Yep, just wondered.

Sorry, I have felt a little defensive since starting this thread.

--
Posted via a free Usenet account from http://www.teranews.com

[philicorda[_3_]]

On Thu, 19 Apr 2007 16:29:44 -0700, Tobiah wrote:

Do you use Linux exclusively
? Given that 90% of Linux soundfile players seem broken wrt BWF BWF, maybe
time to reconsider !

Yeah, I don't even have a Windows box available right now.
This is a rather anomalous bug that was left unaddressed because
no one was having a problem playing their .wav files. The BWF has
exposed this incompatibility with the format spec, and the authors will
likely be responsive. A great many Linux audio programs use a
library called 'libsndfile' to access audio files of various formats,
and the author is aware of the BWF shortcoming. When he gets around
to fixing his library, a great many audio players will be repaired.

Shouldn't have long to wait.
I built the prerelease libsndfile-1.0.18pre8 and xmms, mplayer now play
32bit float BWF created in Ardour.
I'm surprised I had not come across this problem before. I guess I don't
play BWF in normal audio players much.

Get it from he http://www.mega-nerd.com/tmp/



Aren't news groups a valid forum for self expression?

Yep, just wondered.

Sorry, I have felt a little defensive since starting this thread.

[Romeo Rondeau]

Scott Dorsey wrote:
Geoff wrote:
Scott Dorsey wrote:
Tobiah wrote:
I just got the Tascam HD-P2, and it turns out
that it saves as a .wav file, but it's a
'broadcast' .wav file, which is a supposedly
compatible extended wav format.

I've known for a long time that 90% of the
soundfile players out there are broken with
I regularly use Broadcast WAV formats and have never had a problem
with anything reading them, including Audacity. Even my old Sonic
workstation which predates the Broadcast WAV standard by many years
works fine.
Do they load up OK on your Teletype terminal ?

Hey, the Sonic has a 68000 host processor with a NuBus-based DSP unit.
It's high tech, man.
--scott

Actually, those Sonic systems are pretty nice editors. The DSP on the
boards does all the work, anyway.

[Tobiah]

There is nothing in the spec that says that the format
chunk has to be anywhere near the beginning of the file.

No, but the HEADER has to start at position zero,

I had time to look at the spec again. From the text:

"There are no restrictions upon the order of the chunks within a WAVE
file, with the exception that the Format chunk must precede the Data
chunk. Some inflexibly written programs expect the Format chunk as the
first chunk (after the RIFF header) although they shouldn't because the
specification doesn't require this."

There it is.

I did not know that the 'Format' chunk had to precede the
'Data' chunk. This explains why so many programs are written
to expect the Format chunk right after the RIFF header. This
has to be true unless some other, less frequently used chunk
precedes the format chunk.

That is the case with files that are generated by the Tascam HD-P2.
The software authors chose to put the 'bext' chunk right after
the RIFF header, and the format chunk comes between the 'bext'
chunk and the 'data' chunk.

Tobiah

--
Posted via a free Usenet account from http://www.teranews.com

[Tobiah]

Converting to floats and back is pretty much a non-issue.

Well, I suppose that if you are looking at a simple round trip,
the errors would be in effect on the way in, and on the way out,
so one would get the same data out.

There are rounding errors however when the floats are scaled
between 0 and 1, as is done in Audacity. One is asking the computer
to represent numbers like (12543 / 65535) in binary. It can't be done.

After thinking about it though, I don't mind the float conversion
at all. The rounding errors will be minute, and more than made
up for in most processing cases. Suppose you have a sample that
reads 512 in a 16 bit file. Now, multiply by 1.001 to increase
the volume, and you still get 512 ( int(512.512) == 512 ).

Do this 20 times, and that sample has not changed, but samples
greater than 1500 go up a unit each time. Floats get around this
problem to a great degree.

Tobiah

--
Posted via a free Usenet account from http://www.teranews.com

[Erik de Castro Lopo]

Tobiah wrote:

There are rounding errors however when the floats are scaled
between 0 and 1, as is done in Audacity.

Actually, its -1.0 to 1.0.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
"Any verbose and tedious solution is error-prone because
programmers get bored" -- Bjarne Stroustrup
So what about C++?

[Tobiah]

Erik de Castro Lopo wrote:
Tobiah wrote:

There are rounding errors however when the floats are scaled
between 0 and 1, as is done in Audacity.

Actually, its -1.0 to 1.0.

Erik

Oh yeah, thanks. It looks like you added support for
the bext chunk to libsndfile last year. Cool.

Tobiah

--
Posted via a free Usenet account from http://www.teranews.com