Pyramix Illegal Wav Files

[TonyF]

I just came home from a recording project in St. Petersburg Russia with a hard-drive full of Pyramix polyphonic wav files. They played fine on the Pyramix system in St. Petersburg but they do not play on anything home here in the UK, except maybe another Pyramix system (which we do not own). We have two SADiE workstations also Sony Vegas and Adobe Premiere Pro (64bit) all of which report the big Pyramix files as ""unsupported format or damaged file".

Anyone got any tips? The 'illegal' Pyramix files are sixteen-channel 88k2/24 polyphonic wavs and most are larger than 4GB. I guess I need to split the polyphonic files into mono wavs. WaveAgent can only cope with up to twelve channels. BWFSplitter reports the 'larger than 4GB' as invalid.

I contacted Pyramix but they have not replied. My understanding is that a wav file is a RIFF file with 32bit addressing so 4GB is the maximum amount of data which can be addressed. I have heard of possibilities for a wav64 format, but these big Pyramix files larger than 4GB just appear to be some kind of in-house bodge which only works on Pyramix workstations.

[apple-q]

If they are larger then 4GB they are RF64 files. This format isn´t supported by most DAWs but it´s an EBU-standard.

Normal WAVs only support 4GB max.

I think samplitude and wavelab (maybe nuendo?) support it so you could use that to split & convert them. Or find a Pyramix and convert them.

Or download http://ardour.org/ I think it´s free and supports RF64

[TonyF]

Thank you for the tip. I downloaded a demo of Samplitude and am just testing the method on one of the files which read fine. There are about 20 hours to transfer which is a bit of a pest.

[philper]

On PC, BWF Widget (BWF-O-Matic), up to 24 chan. from regular BWF polys (under 2 GB) has worked very well for me.

Philip Perkins

[apple-q]

Originally Posted by philper

On PC, BWF Widget (BWF-O-Matic), up to 24 chan. from regular BWF polys (under 2 GB) has worked very well for me.

Philip Perkins

AFAIK, it doesn´t support RF64.

[kk@jamsync.com]

Originally Posted by TonyF

I contacted Pyramix but they have not replied. My understanding is that a wav file is a RIFF file with 32bit addressing so 4GB is the maximum amount of data which can be addressed. I have heard of possibilities for a wav64 format, but these big Pyramix files larger than 4GB just appear to be some kind of in-house bodge which only works on Pyramix workstations.

Gak...dumb move on their part. They don't have the market share to force something like that.

[apple-q]

Originally Posted by kk@jamsync.com

Gak...dumb move on their part. They don't have the market share to force something like that.

Hm. At least it´s an official standard to overcome the limitations of regular BWAV especially with interleaved BWAVs of that size wich you reach very fast when you record high sample-rates.

I´d say the ones who don´t support it limit themselves and their users...but I guess it´s a question from which side you´re looking at it.

I guess it´s the old VHS vs. Betamax story.

[kk@jamsync.com]

Originally Posted by apple-q

Hm. At least it´s an official standard to overcome the limitations of regular BWAV especially with interleaved BWAVs of that size wich you reach very fast when you record high sample-rates.

I´d say the ones who don´t support it limit themselves and their users...but I guess it´s a question from which side you´re looking at it.

I guess it´s the old VHS vs. Betamax story.

I think they suffer from the "not invented here syndrome"...what good is a "standard" if hardly anyone uses it among US companies? Or Japanese companies? Are there a lot of big companies supporting it yet? Doesn't look like it.

I understand the reason for it; I just don't think that company or even two European companies has the market share to push it. I know it's EBU, but how many companies are supporting it and why is the AES not on board? Why is it not an AES/EBU standard? It's one thing to push for a better concept, yet quite another to leave hapless users in the lurch by not informing them that this "standard" is not universally accepted yet.

The fact that there is a thread like this lends support to that. I'm all for it...just let it be a real standard, not a unilateral "standard". FWIW, I wish AAC were more universally accepted also.

[Muser]

this site is always interesting to check.

http://www.fmjsoft.com/awframe.html

not sure how up to date the formats are but it looks like there are two types of .WAV file formats oddly enough.

on that .F64 it seems to imply it is mono as of the standard. Pyramix have probably custom extended the format. They might not want to give you some bad news that it is a custom format. not sure. There maybe some way to extract that data but I suppose you would need a 64 bit architecture machine to do that because of the memory. and even then. no certainty.

QUOTE:
.F32/.F64 - Floating point raw 32/64-bit IEEE data

Notes:
If you try to read data that actually aren't IEEE floating point as .F32/.F64,files, then the application may hang with an invalid floating point exception error.

Features:
32 / 64-bits floats, mono.

Supported by:
Awave Studio (read + write).
Awave Audio (read + write).
ACDR (write only).

[kk@jamsync.com]

Originally Posted by apple-q

Hm. At least it´s an official standard to overcome the limitations of regular BWAV especially with interleaved BWAVs of that size wich you reach very fast when you record high sample-rates.

I´d say the ones who don´t support it limit themselves and their users...but I guess it´s a question from which side you´re looking at it.

I guess it´s the old VHS vs. Betamax story.

Doesn't the BWF-E handle this and isn't it supposed to be compatible with RF64? (I just looked this up)...what I'm saying is if BWF-E is compatible with the EBU standard, why are we having this thread?

http://www.aes.org/tmpFiles/aessc/20...am1-2008-i.pdf

Please bear in mind that I'm still really irritated that Digi simply ignored my (and others') requests please to make the multichannel metering standardized on SMPTE/ITU or at least give us a choice, so I'm an equal opportunity curmudgeon...

[kk@jamsync.com]

Originally Posted by Muser

this site is always interesting to check.

http://www.fmjsoft.com/awframe.html

not sure how up to date the formats are but it looks like there are two types of .WAV file formats oddly enough.

on that .F64 it seems to imply it is mono as of the standard. Pyramix have probably custom extended the format. They might not want to give you some bad news that it is a custom format. not sure. There maybe some way to extract that data but I suppose you would need a 64 bit architecture machine to do that because of the memory. and even then. no certainty.

Great stufff...thanks!

[Muser]

Originally Posted by kk@jamsync.com

Great stufff...thanks!

you're most welcome.

It may very well be useful to record a short polyphonic Pyramix file and send it to the gentleman behind that site.

He is famous for his knowledge in file formats. He may well be very interested in that format. who knows, He may even be able to create a conversion routine in Awave Studio for it too.

He should at least be able to offer some very useful advice.

[kk@jamsync.com]

Originally Posted by Muser

you're most welcome.

It may very well be useful to record a short polyphonic Pyramix file and send it to the gentleman behind that site.

He is famous for his knowledge in file formats. He may well be very interested in that format. who knows, He may even be able to create a conversion routine in Awave Studio for it too.

He should at least be able to offer some very useful advice.

If the originator of this thread would do that, it would certainly be useful.

[philper]

Originally Posted by apple-q

AFAIK, it doesn´t support RF64.

I wrote Courtney Goodin about it, if it doesn't it would be great if he'd add that as an upgrade--esp since I think we'll see more use of this format in the future.

Philip Perkins

He said nope. (Too bad.)

Philip Perkins

[kk@jamsync.com]

Originally Posted by philper

I wrote Courtney Goodin about it, if it doesn't it would be great if he'd add that as an upgrade--esp since I think we'll see more use of this format in the future.

Philip Perkins

Still doesn't answer the question about Pyramix sticking to the strict format or if BWF-E is really compatible...or who is compatible with whom using which format at the moment. Would definitely be good to have a compatibility table on this.

[apple-q]

Originally Posted by kk@jamsync.com

Still doesn't answer the question about Pyramix sticking to the strict format or if BWF-E is really compatible...or who is compatible with whom using which format at the moment. Would definitely be good to have a compatibility table on this.

The OP has already confirmed that the files can be read with samplitude. Others read the files fine as well. It´s not some secret pyramix-format. It´s called RF64 and it´s been stadardized as an extension to the BWAV format.
Just because ProTools doesn´t read it doesn´t mean it´s non-standard. Heck, PT doesn´t even support SMPTE track layout. Now, how "industry leading" is that?
Pyramix is also a DSD mastering workstation. With high Fs you reach the 4GB pretty quickly so using RF64 is only logical, IMO.

Of course as a user you have to know this and it makes no sense to record to RF64 or chose that as your delivery format if you want to continue your work on a DAW that doesn´t support that standard.

[kk@jamsync.com]

Originally Posted by apple-q

The OP has already confirmed that the files can be read with samplitude. Others read the files fine as well. It´s not some secret pyramix-format. It´s called RF64 and it´s been stadardized as an extension to the BWAV format.
Just because ProTools doesn´t read it doesn´t mean it´s non-standard. Heck, PT doesn´t even support SMPTE track layout. Now, how "industry leading" is that?
Pyramix is also a DSD mastering workstation. With high Fs you reach the 4GB pretty quickly so using RF64 is only logical, IMO.

Of course as a user you have to know this and it makes no sense to record to RF64 or chose that as your delivery format if you want to continue your work on a DAW that doesn´t support that standard.

I'm fully aware of what Pyramix is and is not. We've had various versions in for review here over the years. I did one of the reviews of it for Mix years ago <yawn>. I found the system to be limited at that time because the company did not seem to think that QT playback within the system was important at all and that post would forever involve synchronization with cables and various servo mechanisms. This was approximately at the same time that I would be loading a project in Nuendo on my Titanium and flying from coast to coast merrily laying FX to picture.

It also isn't just PT, it's SADiE not reading these files, apparently. If you don't think SADiE is a mastering workstation, i suggest you say that to Glenn Meadows...and then duck.

As for "continuing [my] work on a DAW that doesn't support that standard", I'll thank you not to make assumptions on how I work. In fact, I work and have worked on various platforms over the years.

My point was that the situation with the original poster never should happen if this is really a "standard". It's not fair to end users who need to transport their files across various platforms all over the world. It's obvious that it certainly isn't universally implemented, unlike the "non-extended" BWF and AIFF.

FWIW, AIFF also supported multichannel from its inception, but the order was akin to SDDS as I recall. I believe the AIFF format extends back into the 80's when the Amiga crowd and Electronic Arts were moving artistic technology along at an amazing clip...I think the audio version of IFF followed from the graphics IFF when Apple saw the cool stuff that was happening on the Amiga and decided to push a real audio standard forward. Now that's a company with the market share to develop a standard!

When the eternal "analog tape vs. digital anything" for archiving format discussions used to come up in the late 80's and early 90's, I would always suggest AIFF because it supported multichannel and people in the music biz would say, "why would we ever care about multichannel?" How amusing that now I find myself apparently being "schooled" on this subject...

So...after 25 years with a file format that supported multichannel, manufacturers still haven't gotten it together to really agree (as in call it the same name) and implement (as in no failures between DAW transfers) a standard for a freaking FILE FORMAT for multichannel. The AES has to call it their name, the EBU another and no one is really sure which workstation will communicate fully with another in this file format exchange. It's not like AIFF and WAV, not yet and not by a long shot.

[apple-q]

I think we actually mean the same thing (kind of...). I was talking about international standards vs. industry standards.

Some companies refuse to comply to standards (See SMPTE ignorance of PT, or no support for 4GB BWAVs for years and years untill v.8 was released, FCP ignoring BWAV meta-data for years and still doesn´t read it fully, AVID ignoring iXML and so forth) some step forward and implement what´s being standardized.

When I wrote "you" I wasn´t talking about you personally but the user in general.

I´m pretty sure you can set Pyramix to record various formats and that the RF64 is an option not the only format. If this is true it´s obviously a user-error to deliver this format if you know the rest of your workflow doesn´t support it. If I´m wrong I agree with you and it would be a stupid move to force users into RF64. No argument about that.

I´d rather have a DAW that supports all international standards than one that doesn´t.
Especially with high Fs recordings the advantages of RF64 are pretty obvious so to me it seems like a completely logical step to implement it.

[dbrulhart]

Dear Tony,

It has come to our attention that you've had problems with so called "illegal" Pyramix files. Even if the Merging team did indeed contact you after two days, we thought important to clear up the situation on this forum for the benefit of some other users.

As apple-q states, implementing RF64 would be a logical step, and I've the pleasure to inform you that this is actually the case in Pyramix since years.

To handle the 4GB barrier when recording Wave/BWF, Pyramix transparently switches to RF64 when the 4GB limit is reached during the recording.

You can find on page 311 of the Pyramix User Manual the extract quoted below.

Merging has solved the 4GB problem since the very beginning of its existence by creating the PMF proprietary file format, but as soon as a 64 bits based format has been standardised in the industry it has been supported.

We can only regret that some other manufacturers haven't been as reactive as we always tried.

So, your files are perfectly valid and you can use them in any application supporting RF64.

Hoping this solves and clears up the situation.

Best regards,

Dominique



File Size Limitations:

By design SD2 and legacy WAV or BWF files are limited to a maximum of 2GB, sometimes 4GB due to their 32bit
signed addressing (thus 31 available bits) formats, while 32bits unsigned addressing AIF files are limited to 4GB.

Pyramix's WAV/BWF Media handler now accomodates RIFF64 removing the 2/4GB limitation. It does this in the following
way: Up to 4GB Pyramix creates a regular (legacy) WAV/BWF, but when a recorded media exceeds 4GB, for
example during a recording/render or mixdown, Pyramix will automatically and transparently start creating a
RIFF64 instead of a regular WAV/BWF.

When performing file interchange please be aware that the destination workstation/software must be compatible
with RIFF64 WAV/BWF to be able to read RIFF64 WAV/BWF files.
Similarly, some "old" applications may only recognize WAV/BWF as proper files if their file size remains below the
2GB limit.

[kk@jamsync.com]

Originally Posted by apple-q

I´d rather have a DAW that supports all international standards than one that doesn´t.

No argument there, but I'd rather have all manufacturers and orgs agree on one standard with one name and a clear specification. We end users have more to worry about in these tough economic times than dealing with the territoriality of manufacturers and trade organizations.

[Andy Le Vien]

Originally Posted by dbrulhart

Dear Tony,

It has come to our attention that you've had problems with so called "illegal" Pyramix files. Even if the Merging team did indeed contact you after two days, we thought important to clear up the situation on this forum for the benefit of some other users.

As apple-q states, implementing RF64 would be a logical step, and I've the pleasure to inform you that this is actually the case in Pyramix since years.

To handle the 4GB barrier when recording Wave/BWF, Pyramix transparently switches to RF64 when the 4GB limit is reached during the recording.

You can find on page 311 of the Pyramix User Manual the extract quoted below.

Merging has solved the 4GB problem since the very beginning of its existence by creating the PMF proprietary file format, but as soon as a 64 bits based format has been standardised in the industry it has been supported.

We can only regret that some other manufacturers haven't been as reactive as we always tried.

So, your files are perfectly valid and you can use them in any application supporting RF64.

Hoping this solves and clears up the situation.

Best regards,

Dominique



File Size Limitations:

By design SD2 and legacy WAV or BWF files are limited to a maximum of 2GB, sometimes 4GB due to their 32bit
signed addressing (thus 31 available bits) formats, while 32bits unsigned addressing AIF files are limited to 4GB.

Pyramix's WAV/BWF Media handler now accomodates RIFF64 removing the 2/4GB limitation. It does this in the following
way: Up to 4GB Pyramix creates a regular (legacy) WAV/BWF, but when a recorded media exceeds 4GB, for
example during a recording/render or mixdown, Pyramix will automatically and transparently start creating a
RIFF64 instead of a regular WAV/BWF.

When performing file interchange please be aware that the destination workstation/software must be compatible
with RIFF64 WAV/BWF to be able to read RIFF64 WAV/BWF files.
Similarly, some "old" applications may only recognize WAV/BWF as proper files if their file size remains below the
2GB limit.

Does "Automatically and transparently" mean "Without informing the user?"

[huub]

It means it does not stop recording...
Are we going to blame pyramix now for Tonys problem? That's nonsense..

[haberdasher]

Pyramix's manual actually contains a reasonably useful discussion of file formats it supports. It's not a bad idea to read through whatever DAW you use.

[tribeofenki]

This thread is interesting. Really pyramix gets it value as a multiformat DAW reader. This means that others will be left with less formats compatibility. Pyramix has not to be blamed for sure here.

[kk@jamsync.com]

Originally Posted by i604

This thread is interesting. Really pyramix gets it value as a multiformat DAW reader. This means that others will be left with less formats compatibility. Pyramix has not the be blamed for sure here.

It's not about blame...it's about portability of the format. It's about making it easier for the users to transport data among various setups instead of making it HARDER for the user. Data transport formats shouldn't be user hostile and users shouldn't suffer when attempting to load a simple audio file into a DAW. Project files are a different animal, but this problem with incompatibility of multichannel files has gone on far too long.

I won't even go into the havoc that it is wreaking in the BluRay authoring community. People want to simply use multichannel 48kHz files, but can they with most commercial BluRay authoring packages? NO. While claiming to be "transparent", they, in fact fail because of this very problem, so a lot of the packages really only support stereo.

[tribeofenki]

Agree totally about user-side portability. RF64 has been specified by the European Broadcasting Union (EBU). More DAWs should include this format compatibility.

INFO: http://tech.ebu.ch/docs/tech/tech3306-2009.pdf

Note that into the 3D Compositing world there are a lot of proprietary formats.
Finishing a project means sometimes to move to different applications: a real nightmare. At least where some standards are achieved - as in this issue - companies should really worry a little more about the final user. Blu-ray is owned by a Consortium composed by many companies, while DSD is Sony/Philips proprietary.

[philper]

Originally Posted by i604

Agree totally about user-side portability. RF64 has been specified by the European Broadcasting Union (EBU). More DAWs should include this format compatibility.

INFO: http://tech.ebu.ch/docs/tech/tech3306-2009.pdf

Note that into the 3D Compositing world there are a lot of proprietary formats.
Finishing a project means sometimes to move to different applications: a real nightmare. At least where some standards are achieved - as in this issue - companies should really worry a little more about the final user. Blu-ray is owned by a Consortium composed by many companies, while DSD is Sony/Philips proprietary.

I'd like to be able to use this format but I'd need to find a stand-alone utility that I could offer clients to crack them with before I could adopt it (I mean other than buying a Pyramix). Something like a souped up Wave Agent or BWF-O-Matic.

Philip Perkins

[apple-q]

I have posted before that there are a bunch of apps out there that support it and some are even free (ardour).

If you scroll up you will find them.

[TonyF]

Thank you everyone for helping me. My email to Merging had got lost in someone's spam folder and was dealt with very promptly when it was discovered.

There are several DAW applications which have no problems with RIFF64, others which do. There are several DAW applications which won't run on a 64bit PC, others which do. As a user this is all a bit of a pain in the neck. These formats should be universally available or alternatively there should be 'health warnings' for users.

You can buy a GBP500 interface and the free bundled software can run on 64bit and read/write RIFF64. You can spend thousands on the fanciest biggest names and they can do neither. These are frustrating and annoying times where manufacturers think and operate in a vacuum.

I want to buy a new laptop and all the preferred models come 64bit and several leading brands of DAW applications including SADiE, Pyramix, ProTools(?) will not work on any of them without installing dual-boot and 32bit OS. The PC industry is embracing USB 3.0 SuperSpeed yet I have seen no audio interfaces yet, apart from the Blackmagic multimedia one.

[tribeofenki]

^ Agree. Here's the common final-user issues:

The OS (...)

The interfaces (USB 2.0 3.0, Firewire - see Apple - PCIe and the related Motherboard problems.

Drivers (...)

The DAW itself and its capabilities, reliability and so on.

At last, but not at least... the formats.

After all those issues you fall into this crap of different encodings,
different strings that define the F**KING same piece of audio.

The most hated issue is the different formats IMHO