[Rwp] rendering again
Chris Belle
cb1963 at sbcglobal.net
Tue Oct 20 23:10:38 EDT 2015
Hey, I've been experimenting with rendering different bit depths again.
Here are some interesting things to note.
I used a test file which was recorded at 16 bits, captured from a xm
radio feed.
I wasn't so interested in the quality of the actual material as much as
how it would act in different processing situations.
The 16 bit options act as you'd expect, when rendering something out
down at 80 db down, you get ragged edges, the audio sucks,
when no dither is applied.
Now when applying dither, it sounds better, and the noise shaping in
reaper is rather nice.
But strangley, it does not show up unless you select the master mix as
your options for mix down, and ou have to go and select time selection
and such from with in that preset, you can't just select item mix down
even in that same dialogue,
you won't have your dither or noise shaping check boxes.
The noise shaping makes the audio a bit quieter, but it does take care
of the ragged edges.
I normalized in sound forge to listen to the audio and the effects of it
dithered out down low like that.
Oi,k well and good, so I moved to 24 bit.
I used the same 16 bit file but now I dropped the out-put for mixing
down to minus 135 db instead of 80.
Same deal, ragged edges, but when applying dither and noise shaping, it
got better,
with only dither the out-put was louder when normalized, but nicer when
using noise shaping.
Now here's what's really the part that interests me.
When I moved to 32 bit floating point and dropped the out-put down all
the way as far as reaper would let me down to minus 150 db, the noise
shaping and dithering options went away totally, not to be seen anywhere
in that dialogue.
But the rendered files sounded great.
I also tried it with 64 bit floating point,
most of the players on my system won't even start up with a file like
that but soundforge took it.
And it played well too, even
rendered way down low,
I could not get those ragged tails to show up like I could with 16 bit
or 24 bit.
So there is a significant quality difference beween 24 bit linear and 32
bit floating point.
Not for normal listening levels, but on the raged edges way down low, it
does matter, and so I think it might be a good idea to dither or noise
shape even when rendering out 24 bit files,
at least in some cases.
Maybe not for the weekly radio broadcast, but for the archives, for high
quality things, you might even consider keeping a 32 bit or 64 bit
vfersion of it
or at least a dithered and noise shaped 24 bit version.
Of course, it goes without saying, ou should always dither a 16 bit
render, the only time I might not do that is if I know for sure that all
the processes and data paths are only 16 bit all through the project.
This would mean setting reaper's mixing bit depth to 16 bits,
and using only 16 bit plugs, which are pretty much a thing of the past,
and even then dithering wouldn't hurt,
because your gain staging is never 100 percent perfect on everything,
and in the bad old 16 bit days, if you had any tracks recorded at lower
levels, you would always have some ragged tails.
I guess the point of all this was to see if it'd be worth dithering for
24 bit, or just eating the extra disk space and going for the 32 bit
floating point or the 64.
I think it might be worth at least going for the 32 bit floating point,
for renders and gluing,
that's only just a bit more disk space than 24 bit rendering,
I realize that some systems can not use 32 bit files,
but I think it is well worth dithering at that point if there is any
chance of hearing those low level tails.
The difference between 135 db and 150 db, I know we're talking a
ridiculous amount of range which we would almost never encounter in our
daily work, but it is there none the less,
so for those who are purists,
and want the best you can get,
out of reaper,
and remember, rounding errors through lots of processing are cumulative,
so I think I may compromise and set reaper the same as sonar which
defaults to 32 bit floating point,
I actually have some sample libraries which are done in such,
a nice yamaha piano in dimension pro format,
recorded by digital sound factory,
it's not my most favorite piano,
but it is most definitely recorded with very high precission,
and I do understand why they rendered it in 32 bit floating point,
because some of those notes sustain forever.
With in-put and out-put hardware, connected to the real world, there is
some bit padding that goes on,
but my experiments tell me that our DAW's can indeed use those extra bits,
internally at any rate,
it allows place holders,
when gain staging or needing more headroom in the numbers realm,
I don't pretend to understand all the math involved, but my simple trial
casual experiments tell a lot with what's going on, at least to my
satisfaction.
On 10/20/2015 7:33 PM, Chris Belle wrote:
> Ha, we both came to similar experimental ideas at the same time 'grin'.
>
> Your listening
> or capturing hardware shouldn't
> matter so much for the internal data bus width testing,
> as when I set the mixing depth in reaper to 64 bit, even 16 bit
> streams allowed me to turn it all the way down to -140 -150 and still
> sound good.
> But when I dropped it to 32 and 24 bits, that low level started to get
> ragged.
>
> That mackie is only low level like that on the master bus,
> I do wish it was adjustable, but it's like that so you can feed
> multiple tracks to the master bus
> and not exceed nominal levels.
>
> But recording to the individual in-puts or to the subs, the gain
> staging is pretty spot on.
> and I can easily get -12 or -6,
> but when you hit 0 you are clipping.
>
> Try using a sub pair instead of the master bus,
> to sum your signals and you will get gain from all the faders involved,
>
>
>
>
> On 10/20/2015 5:22 PM, Snowman via RWP wrote:
>> Chris, Yep about all that.
>> The problems start to appear when one goes looking for them.
>> And, of course the A/D converter resolution is, how many bits? Maybe 24?
>> Interesting experiment is to poke nice smooth white noise into an
>> analog input, and drop the drive level way way down, and the
>> listening volume way way up. If nothing bad happens to you, you'll
>> start to hear that coarsness taking hold at lower levels.
>> But, you really have to go low to hear that. Try it with 8 bitgs, if
>> you wonder what we're talking about.
>>
>> But, if it's true that modern systems are hardly bothered by the
>> extra data of 64-bit, why not use it for internal work.
>>
>> I use higher bit depts when sucking from the Mackie Onyx firewire,
>> since it loves to make you operate down around -20 to -30DB. In that
>> case, you really have to have it.
>>
>>
>>
>>
>> ----- Original Message ----- From: "Chris Belle via RWP"
>> <rwp at bluegrasspals.com>
>> To: "Reapers Without Peepers" <rwp at bluegrasspals.com>
>> Cc: "Chris Belle" <cb1963 at sbcglobal.net>
>> Sent: Tuesday, October 20, 2015 4:56 PM
>> Subject: Re: [Rwp] rendering again
>>
>>
>> Hey Jim?
>>
>> I have done some casual testing with sonar and rendering out 16 bits and
>> 24 bit files with a very long piano fade,
>> like you'd get on the low a.
>>
>> It's quite significant with 16 bit
>>
>> even compared to 24 bit, it made a difference in half a minute worth of
>> fade.
>>
>>
>> You did have to turn the volume way up to hear it, or normalize the tail
>> up so you wouldn't have to turn the amp way up, but
>>
>> 16 bit tails would fade out or get jittery around 84 db down while 24
>> bit tails didn't get that way till about 137 db down.
>>
>> With dithering it made the tails smoother.
>>
>> the problem with this isn't so much what bit depth you use, 32 or 64
>> bit, either would be pretty darn fine res, but when you go back and
>> forth between say 24 bit and then back to 32 bit.
>>
>> If you render your stems out for gluing and such as 24 bit stems, and ok
>> at that point they are good for use with any input to sound cards or
>> what ever, where as 32 or 64 bit floating point wavs are only good for
>> internal use for the most part.
>>
>> but all those extra bits from a 32 or 64 bit wav that you did use would
>> get truncated,
>> and then when you re-introduced the 24 bit wav back in to your
>> processing in your project it get's translated back to 32 or 64 bit so
>> where the extra wide data path might matter is if you weren't all the
>> way to the top of scale say you had some stuff you were rendering and
>> you were down
>> -20 db, well at 24 bit you're still having a wide margin of error, but
>> with 32 bit or 64 bit you are really safe.
>>
>> Most people would never turn their amps up that loud, but say if you
>> were listening in a concert setting with classical music with a very
>> wide dynamic range, and delicate instruments at low levels
>> which might be afected by the noise floor then that extra margin might
>> matter.
>>
>> 24 bit is still pretty good even not dithered, but if you use dither to
>> mask your tails,
>> or use a high enough bit depth so you never ever reach the edge of the
>> data stream before the tail runs out,
>> and give yourself more than enoughroom for processing, like we know our
>> eq's and compressors and such like 32 or 64 bit data paths,
>> then to me it makes sense to keep it big and wide until you reach the
>> real world.
>>
>> Your also following the practices of the dsp chip makers at this point,
>> even dsp chips of 15 years ago made our digital mixers and such with 36
>> bit data paths, for instance the delta card is 36 bit
>> 4 bits bigger than the 32 bit floating point sonar defaults to, the
>> behringer x32 is 40 bit,
>> I think the RME stuff is 64 bit,
>> so could we hear it, probably at 24 bit you could hear some of it under
>> certain circumstances,
>> probably not so much at 32 or 64 bit.
>>
>> A lot would depend on the type of listening; you were doing, and the
>> type of processing,
>> but the way to test any of this stuff is to listen to the tails and the
>> edges of things when they fade out.
>>
>> Like I said, my testing was casual, and only with sonar's dithering and
>> rendering so far, I plan to do some with reaper,
>> but it is telling to me that sonar uses dithering even at the higher bit
>> depths,,
>> and defaults to a higher bit depth internally
>>
>> You certainly wouldn't notice it on your typical podcast, or audio book,
>> heck with those you probably wouldn't notice it doing 16 bit with no
>> dither.
>> even.
>> Certainly not at low level casual listening living room volumes.
>> but if you were going to pay attention to such details, sonar's default
>> setting are much better for full proofing this sort of thing than
>> reaper's is.
>> YOu don't get the internal dithering with reaper, but you can certainly
>> turn the data path up big and wide so you never deal with the tails of
>> things so to speak.
>> Or use the render options in reaper that allow you to dither and noise
>> shape,
>> it's kind of a pain to do so instead of the convenient glue and render
>> options offered internally,
>> but at least then you know you would have done everything possible to
>> make your files as transparent as possible.
>> I think I'd trust it all at 64 bit,
>> rendering,
>> one could also do some screwy things like turn one bus way down and
>> another way up that were in series, totally do your gain staging wrong,
>> to see how far you could push things to the edges of your data streams
>> and see how they act with and without dithering,
>> but with normal best practices, 32 or 64 bit rendering would give you
>> very nice results with or without dithering.
>> bu the dithering gives you just that little bit more safety in case
>> something screwy happens, you'd get a smooth noise floor sound instead
>> of a jittery ragged quantizing
>> error when you ran out of bits.
>>
>> Very much hair splitting here I know for every day practices, but yes, I
>> too am interested to see what others do besides me and Justin and
>> Patrick at this point.
>>
>>
>> But I am talking best practices senarios here for future proofing
>> projects,
>> On 10/20/2015 4:11 PM, Snowman via RWP wrote:
>>> I'm curious. Have any of you guys with good hearing actually tried
>>> to demonstrate the distortion that results from using lower bit
>>> depths? Mathematically, I know it is better. But, can you hear it?
>>>
>>> The resolution of 32-bit is pretty significant.
>>> and 64-bit is just obscene, which is why they don't mess with
>>> dithering at such high depths.
>>> When I could hear worth beans, it was clear that you started to hear
>>> obvious quantization when you dropped below 16, especially the
>>> texture of very soft sounds, which wasn't apparent unless you turned
>>> the gain way up.
>>> 32 bits is 65,000 times finer resolution. If you look at the
>>> quantization error of even 32 bits, it is very tiny, something
>>> better than oned part in 4 billion, which is 0.000000025 percent.
>>> and 64 bits is incredibly fine resolution.
>>> So, is it, really, necessary, or just better.
>>>
>>> ----- Original Message ----- From: "Clarence Griffin via RWP"
>>> <rwp at bluegrasspals.com>
>>> To: "'Reapers Without Peepers'" <rwp at bluegrasspals.com>
>>> Cc: "Clarence Griffin" <goldfingas at gmail.com>
>>> Sent: Tuesday, October 20, 2015 9:05 AM
>>> Subject: Re: [Rwp] rendering again
>>>
>>>
>>> You can change all that in settings though, yes?
>>>
>>>
>>> -----Original Message-----
>>> From: RWP [mailto:rwp-bounces at bluegrasspals.com] On Behalf Of Chris
>>> Belle
>>> via RWP
>>> Sent: Tuesday, October 20, 2015 1:10 AM
>>> To: Reapers Without Peepers
>>> Cc: Chris Belle
>>> Subject: Re: [Rwp] rendering again
>>>
>>> Just to put a little more butter on the bread, about this ever so
>>> contravertial topic, so tp speak, sonar renders everything at 32 bit
>>> floating point if you leave things at default.
>>>
>>> So when you freeze, or bounce anything, you get a 32 bit file
>>> internally.
>>> Many players, and some other DAW's can't handle this format so I
>>> guess that
>>> may be one reason reaper defaults to 24 bit bounces, they call it
>>> glue, but
>>> it amounts to just about the same thing.
>>> making a new file processed from other files.
>>>
>>> Ideally, when you do this, you want to do it to the same size file,
>>> or one
>>> bigger which will ensure you retain the information you had, when
>>> using a
>>> bigger file, the extra bites usually get padded with zeros.
>>> Sonar has dithering options in this rendering bouncing process, in
>>> case you
>>> do decide to use a smaller bounce size, so you can take care of
>>> those tails,
>>> but reaper does not.
>>>
>>> Not obviously on the surface anyway,
>>> so that's why I was thinking of doing all my internal bounces at 64
>>> bit and
>>> only going down to 24 or 16 bitg when I was finished with the projec.
>>> Most people I know using sonar in a high end situation turn
>>> everything up to
>>> 64 bit, as well as checking the box for the 64 bit double precission
>>> engine.
>>>
>>> Whether this makes any detectable difference for most situations is
>>> anybody's guess or conjecture, but I do know if you do this,
>>> rounding errors
>>> become so very negligible.
>>> and so far out there that it's not really a consideration anymore.
>>>
>>> From what I gather, anything above 32 bit is good, and this is
>>> because most
>>> plugs we use process at either 32 bit or 64 bit floating point.
>>>
>>> So having this mixing bit depth internally guarantees that
>>> everything get's
>>> translated, more or less.
>>>
>>> And different pieces of hardware like the behringer board have their
>>> own bit
>>> depth when processing, for the behringer, it's 40 bit.
>>>
>>> Of course, it doesn't make sense to try and use big files outside
>>> our DAW's,
>>> many times I get only white noise when experimentally trying to play
>>> say a
>>> 32 bit floating point file in winamp, and a 64 won't even get
>>> started, I get
>>> a system error.
>>>
>>> But when having a conversation with my mentor Jim Roseberry over at
>>> studiocat.com, who builds the finest DAW's in the land, and is an
>>> endless
>>> wealth of patient knowledge when I've been building my own machines, or
>>> helping others, trying to figure out the best ways to do things, he
>>> says
>>> that 64 bit processing on our modern systems doesn't hit them much
>>> harder,
>>> and it insures the best possible resolution for all the things we
>>> might do,
>>> cuts out those rounding errors, and I think there is probably
>>> something to
>>> that.
>>>
>>> The only time I might ignore this rule is if I were just recording
>>> something
>>> with no processing, no plugs, just wanted a straight bounce of what I
>>> recorded in to straight out.
>>>
>>> At that point, then any 64 bit
>>> wide bus or even 32 would probably be wasted, since you're not going
>>> to do
>>> any mixing.
>>>
>>> I would be curious to hear from others if anyone has ever used any
>>> of the
>>> more unusual bit depth options in the advanced reaper tab, like 12
>>> bit or
>>> even 8 bit.
>>>
>>> Probably be kind of cool for some low fi sort of electronic thing,
>>> though
>>> there are probably better ways to do that with things like bit
>>> reduction
>>> plugs, like some of the j s stuf, but I wonder what the thinking was
>>> to even
>>> include them in reaper?
>>>
>>> Sonar doesn't have such a thing, only the check box for the 64 bit
>>> double
>>> precission engine thing, but nothing for mixing bit depth as such,
>>> but it
>>> does have the extra options dither and such for rendering both for
>>> internal
>>> use, and for export, anyway, these are two entirely different animals.
>>>
>>> On 10/19/2015 10:33 PM, Chris Belle wrote:
>>>> I was speaking of rendered or printed fx to a file.
>>>>
>>>> yes, if you still have the project, it would make sense to go back to
>>>> the project and get it straight from the source.
>>>>
>>>> We can't do anything about media we get from other sources, already
>>>> processed at 16 bit, and 24 bit audio is indeed very wide and not
>>>> likely to have audible artifacts from processing.
>>>> at the normal levels we will use them.
>>>>
>>>> I'm talking about best practices for maintaining the best audio
>>>> quality in house though.
>>>>
>>>> Internally with in your reaper projects.
>>>>
>>>> When you glue, or render, and create a 24 bit file, that is coming
>>>> from a 64 bit wide file, then you are technically throwing away
>>>> resolution.
>>>> Could you hear it?
>>>> Probably not.
>>>> You might not even hear it most of the time if you rendered 16 bit
>>>> unless you turned it way up and caught a grainy tail or something.
>>>> But it's the principal of conservation, of data, you can't get the
>>>> data back once it's gone, kind of like making an mp3 from a wav and
>>>> then getting the wav back, not quite as bad, but once you go from a 64
>>>> bit file to a 24 bit file, say you glued a bunch of stuff and then
>>>> wanted to use it in the same project again, then it returns back to
>>>> the 64 bit environment.
>>>> from a lower bit depth.
>>>>
>>>>
>>>> If you glue at 64 bits, you maintain the same wideness of data path.
>>>>
>>>> That's what I'm getting at.
>>>>
>>>> 24 bits is probably wide enough at any rate though, for most work,
>>>> especially if you only go through the process one time, and don't keep
>>>> going back and forth, but my concern was that there was no dither
>>>> option in reaper when you down size like this, when you go from bigger
>>>> to smaller, you should always dither which takes care of the potential
>>>> for truncated data, so you don't get ragged edges.
>>>>
>>>> 24 bit is huge, and 64 bit is even
>>>> more so,
>>>> noise floors will be something like 135 140 db down, and I don't even
>>>> know what they'd be for a 64 bit file, nothing our systems could
>>>> produce for sure, but I was jus thinking since there is no dither
>>>> internally that I know of keeping things the same till the last dither
>>>> might be the safest, speaking strictly from a technical point of view.
>>>> But 24 bit rendering is not at all a bad compromise, and I would have
>>>> to do some testing with some long tails to see if I could hear
>>>> anything.
>>>>
>>>>
>>>> On 10/19/2015 3:00 AM, Justin Macleod via RWP wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm slightly confused.
>>>>>
>>>>> You said:
>>>>>
>>>>> so considering our plug-ins generally process at 32 or 64 bit if we
>>>>> render out at 24 bit and then brin the file back in for further use,
>>>>> then we theoretically might be throwing away some resolution.
>>>>>
>>>>> But why would we do that? If you needed the file again, why would you
>>>>> not just open the project with it in and copy the audio across? Then
>>>>> you would have the 64-bit version. I totally see the need when gluing
>>>>> items and freezing tracks, but rendering out everything at 64 bit
>>>>> float when you have the projects anyway strikes me as being
>>>>> exceedingly hard-drive space intensive.
>>>>>
>>>>> Plus, how is using 24-bit files that you've have rendered out from
>>>>> previous projects any different from a DJ mixing with 16-bit CD
>>>>> tracks for mix tapes or film production houses using 24-bit sound
>>>>> effects and royalty free music. If you use any third-party media at
>>>>> all in your projects, from sample libraries etc, you're going to be
>>>>> taking the same quality hit as compared to a 64 bit version of the
>>>>> same file.
>>>>>
>>>>> Sorry if I'm being dense and have missed something,
>>>>>
>>>>> Justin
>>>>>
>>>>> *From:*RWP [mailto:rwp-bounces at bluegrasspals.com] *On Behalf Of
>>>>> *Tayeb Meftah via RWP
>>>>> *Sent:* 19 October 2015 08:14
>>>>> *To:* Reapers Without Peepers <rwp at bluegrasspals.com>
>>>>> *Cc:* Tayeb Meftah <tayeb.meftah at gmail.com>
>>>>> *Subject:* Re: [Rwp] rendering again
>>>>>
>>>>> HELLO Chris
>>>>>
>>>>> out of subject question
>>>>>
>>>>> i wonder are you a blind person?
>>>>>
>>>>> or a sighted person helping here?
>>>>>
>>>>> thank
>>>>>
>>>>>
>>>>> Envoyé de mon iPad
>>>>>
>>>>>
>>>>> Le 19 oct. 2015 à 05:56, Chris Belle via RWP <rwp at bluegrasspals.com
>>>>> <mailto:rwp at bluegrasspals.com>> a écrit :
>>>>>
>>>>> Been reading the manual and playing with reapers different
>>>>> options
>>>>> for rendering and bit depth and dithering and such.
>>>>>
>>>>>
>>>>> I noticed, when you consolidate or export tracks,
>>>>> there is no option for dither there.
>>>>>
>>>>> When you render to a bigger bit depth than you are recording,
>>>>> the extra bits are padded with zeros theoretically, but when you
>>>>> go the other way, you want something to fix up those rounding
>>>>> errors, or ragged tails you might have on the ends.
>>>>> way down low.
>>>>>
>>>>> You'd never hear it probably with any modern mix hugging the top
>>>>> end of the scale, but sonar has dithering options all through the
>>>>> architecture,
>>>>> you can set dither for triangular or rectangular, or pow r 3, or
>>>>> turn it off is you want, but the only place I find it in
>>>>> reaper is
>>>>> a single noise shaping option and dither option for rendering.
>>>>>
>>>>> so because of that reason, I wonder if maybe best practice in
>>>>> reaper is to set everything the same across the board the same
>>>>> until you are going to do your final render.
>>>>>
>>>>> In other words, since reaper defaults to 64 bit mixing resolution
>>>>> then maybe we should render to 64 bit floating point.
>>>>> Sonar's rendering is set to 32 floating point by default,
>>>>> and there is a check box to check and uncheck the 64 bit double
>>>>> precission processing engine, which probably equates to
>>>>> reapers 64
>>>>> bit internal mixing depth,
>>>>> so considering our plug-ins generally process at 32 or 64 bit
>>>>> if we render out at 24 bit and then brin the file back in for
>>>>> further use, then we theoretically might be throwing away some
>>>>> resolution.
>>>>>
>>>>> But leaving everything at 32 or 64 bit, and leaving any shaving
>>>>> down of the file till the very last would guarantee never to
>>>>> introduce rounding errors to the process.
>>>>> The way it is now, if we ever need to use the consolidate options
>>>>> or the batch file processing, and we choose a lower bit rate,
>>>>> than
>>>>> what the files are in at present, then
>>>>> I seriously wonder if reaper does just truncate those extra bits.
>>>>> Also I wonder even when dithering down when we use the render
>>>>> option which does give us that single dither and noise shaping
>>>>> options,
>>>>> even when we are rendering to 24 bit, if we are coming from a 32
>>>>> or 64 bit environment,
>>>>> if we should go ahead and turn on dither.
>>>>> Reaper also has some interesting features that you can't do in
>>>>> sonar, like reducing the mixing latency down to even 8 bits if
>>>>> you
>>>>> like.
>>>>>
>>>>> And some things I've never seen like 39 bit and 12 bit.
>>>>>
>>>>> Which makes me think that maybe if you want to do straight
>>>>> recording, and never dither at all, for something casual, where
>>>>> processing has already been applied,
>>>>> oh, for instance a radio show marathon that went on for a
>>>>> weekend,
>>>>> and you wanted to just go off and leave it and then come back and
>>>>> if you didn't do any volume changes, or any processes inside
>>>>> reaper involving plugs, or gain staging and such, since
>>>>> technically with a DAW, or you don't change a fader anywhere then
>>>>> what you put in should be the same as what you get out,
>>>>> then I wonder if lowering the mixing resolution down to the file
>>>>> format you want, say 16 bit or 24 bit, I wonder if that makes any
>>>>> sense?
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> RWP mailing list
>>>>> RWP at bluegrasspals.com <mailto:RWP at bluegrasspals.com>
>>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> RWP mailing list
>>>>> RWP at bluegrasspals.com
>>>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>>
>>>
>>> _______________________________________________
>>> RWP mailing list
>>> RWP at bluegrasspals.com
>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>
>>>
>>> _______________________________________________
>>> RWP mailing list
>>> RWP at bluegrasspals.com
>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>
>>>
>>> _______________________________________________
>>> RWP mailing list
>>> RWP at bluegrasspals.com
>>> http://bluegrasspals.com/mailman/listinfo/rwp
>>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>>
>> _______________________________________________
>> RWP mailing list
>> RWP at bluegrasspals.com
>> http://bluegrasspals.com/mailman/listinfo/rwp
>>
>
More information about the RWP
mailing list