TOPIC:

@ Chris,

If you have any tips and tricks that we could add to the page of this site (www.minidsp.com/applications/advanced-to...open-room-correction), do let us know. We'd certainly love to make it easier for the community. PORC having some great potential I believe.

DevTeam

devteam wrote:

@ Chris,

If you have any tips and tricks that we could add to the page of this site (www.minidsp.com/applications/advanced-to...open-room-correction), do let us know. We'd certainly love to make it easier for the community. PORC having some great potential I believe.

DevTeam

Will report back when I have something to share.

In terms of changes that have happened:
- amended the PORC readme file to reflect changes to code that remove some of the dependencies that previously existed. It is now possible to use Anaconda Python Distribution (and I believe Enthought Python Distribution or Pythonxy would also work)
- I amended the code to no longer require a manual conversion of the wav file to binary format outside of the PORC Python script. I believe this also means that we get true 32bit binary coefficients where was previously not the case (there used to be a conversion that went float64->pcm16->float32) so this might improve the coefficient output now too. I haven't ordered my miniSHARC boards yet so haven't tested these myself though I'm confident in the output after checking the file format by hand and I think Mason may have tested them?
- Mason removed dependency for libsndfile and now uses Numpy for generation of the wav file which makes the install process cleaner/easier.

I had intended to start building a GUI that works by using IPython Notebooks which are a web based interface similar to Matlab and similar analysis packages but quite intuitive to use I find. Some of the features I wanted to use were flagged for imminent changes in the 2.0 release which is due out in Jan 2014 so I put that work on hold until after those changes were made so that I didn't have to rewrite my code for the new software. I also did a review of some of the newer work by Dr Bank and found some of the more recent papers interesting but I haven't yet had a chance to include those.

When I complete that UI work then I will share it back with Mason and if he is happy to include it in the main GitHub repo then hopefully it will be available there and I'll provide a short doc on how to use it also.

In the future I was also planning on writing a Python script similar to PORC based on Eric Lehman's Image Source Method code and papers. I've been too busy reading about all these things trying to understand them (and design some electronics hardware too) to actually get much code written yet, maybe 2014 will be a productive year for me!?


Regards,
Chris

Chris,

Thanks for the follow up and it's really good to see that PORC is still very much maintained! Sounds like there is some exciting work on its way and potential since there is a good user base of OpenDRC end users. I'm sure they'd love to get some updates!

When you have a sec, can you please get in touch directly with our team via Email (info AT minidsp.com) ?Might be some ways that miniDSP could help your endeavors...

DevTeam

devteam wrote:

Chris,

Thanks for the follow up and it's really good to see that PORC is still very much maintained! Sounds like there is some exciting work on its way and potential since there is a good user base of OpenDRC end users. I'm sure they'd love to get some updates!

When you have a sec, can you please get in touch directly with our team via Email (info AT minidsp.com) ?Might be some ways that miniDSP could help your endeavors...

DevTeam

Such is the beauty of open source software - we are free to read and improve on it as we like/need


Will send an email shortly

Chris

Hi East,

If I send you an email would you be able to send me a copy of the two files so I can look into the issue? Or are you able to upload them to somewhere like dropbox and post a temporary link?


Regards,
Chris

@East, Just checking that you got my reply? You should have my email address now


@DevTeam, as you suggested I sent an email to you, did you receive it?

Hi all, first excuse my bad English. I have been tested for this fantastic script DRC, I come to use DRC-FIR (denis sobreing).

I think I've found a bug. I'm running on a machine with windows 8 x64 octave / anaconda. Everything completes successfully.

C:\porc-master>python porc.py -n 32768 -o wav R.wav Req.wav

But when I import the impulse in REW to check. I noticed this to 24bits!

You can also see the size in disk, a stereo filter with 32K has a size about 257Kb. And the resulting files are 193Kb (is a 24bit stereo)

You Might confirm my suspicion?

Thanks to Chris for further work in this simple but effective script DRC.

Correct, currently wav output file is 24bit.

greenm01 (Mason) wrote that code, but, it doesn't appear hard to modify, I'll make a note of it and see if I can make those available for configuration by user of the script.

I change script:

def wavwrite_24(fname, fs, data):
data_as_bytes = (struct.pack('<i', int(samp*(2**23-1))) for samp in data)
with closing(wave.open(fname, 'wb')) as wavwriter:
wavwriter.setnchannels(1)
wavwriter.setsampwidth(4)
wavwriter.setframerate(fs)
for data_bytes in data_as_bytes:
wavwriter.writeframes(data_bytes[0:4])

Change the numer RED. replace number 3 for 4.
Output is 32bits!

The problem now is that the WAV is very attenuated, and my soft of Convolver no audio outputs.

If you import the impulse in REW displayed correctly in 32bit.

I suggest comparing the 32bit wav to the 32bit bin

I suspect the second line might need changing but would need to check it in more detail as I don't fully understand what it is doing in the list comprehension here but the 2**23-1 gets my attention just on glancing at it.

I belive that reference to FS = 44.1Khz

Did some tests tonight, not sure totally what it all means just yet. I'm not sure scipy.io reads 24bit wave files properly so I need to be sure of that before I make any comment on my comparisons, to make sure the values I'm getting back are correct. But at the moment when I read by the wave32 values back, I do get back values that are at least order of 10 less than the wave24 version that Mason wrote.

I'm pretty certain that the scaling factor that I pointed out is not part of the sample rate but is actually a factor for scaling to the integer size. I'm going to have to send Mason a note on that list comprehnsion and ask why the (2**23-1) term is used in that equation, it seems counterintuitive, if it is 0-indexed then 23 would make sense but 22 just doesn't, there is likely a reason I've just totally missed. The sample rate is taken care of a few lines down from there.


Comparison to the floating point binary data isn't as simple as I thought but if you're keen to look at it as a numpy array use:

This will read it back into a python interpreter, I've not worked out the code to convert that back to an equivalent int32 format for comparison.

Hopefully we can get to the bottom of this soon as it is definitely something lacking in PORC. Thanks for your help in trouble shooting and giving feedback!

Cheers,
Chris