From slaw@cci.com Wed Aug 10 13:26:47 EDT 1994 Article: 12315 of comp.sys.amiga.audio Newsgroups: comp.sys.amiga.audio Path: sunsrvr6!slaw From: slaw@cci.com (Scott Lawrence) Subject: Dolby Encoding- More on Phase Shifts Message-ID: Sender: root@sunsrvr6.cci.com (Operator) Organization: Northern Telecom, Network Application Systems Date: Wed, 10 Aug 1994 14:27:18 GMT Just got this mail from wwz1@map.wustl.EDU (Woody). It's one way to do the phase shift for a sound sample, that i think would work. At least it woould work better than mine would, as mine is linear... This has not been tested yet, but here it goes... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . >From wwz1@map.wustl.edu Tue Aug 9 18:42:26 1994 Date: Tue, 9 Aug 94 16:56:12 CDT From: wwz1@map.wustl.EDU (Woodrow W Zenfell III) Message-Id: <9408092156.AA16405@map.wustl.edu.wustl.EDU> To: slaw@sunsrvr3.cci.com Subject: Re: Phase Shifts Status: OR I thought about this method a little bit too and think we may be on to something. The part that confused me was that the very meaning of phase shift is a change in the sample horizontally, not vertically - i.e. means moving (elements of) the sample along the time axis instead of affecting the amplitude. However, I thought again about what you suggested, and I think it's right. For the most part. My thinking includes a little more: it's NOT linear. Here's My Way To Phase Shift (tm): Take a single sample of a sound (one vertical cross section, one number, that is, not a collection of these). Take its ARC SINE in degrees. Add your phase shift to it. Take the SINE of that in degrees, and Poof!! You've phase shifted it! (Right?) This should correctly phase shift a single sinusoid of any frequency, I think, so should work on an arbitrary combination of those. Again, the amount you change the sample by is NOT linear. It is based on the sin function. By the way, a shortcut for doing this would be to take the cosine of the arcsin for one 90 deg shift and the inverse of that for the other. By George, I think we've done it! hehe What do you think? Woody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Woody, I think there might be a small problem. this seems quite processor intensive. Perhaps to do dolbe encoding for a mod player, we encode the sound sample then load it into the player, then when playing it, we just invert it for the other half of the dolby encoding, as we need a +90/-90.. ie. encode +90 once, do the -90 on the fly... -J -- Scott "Jerry" Lawrence __ Amiga: We do more with 7.16 Mhz slaw@cci.com, jerry@csh.rit.edu /// than most do all day http://www.csh.rit.edu/~jerry/ __ /// ----------------------------------- #include "disclaimer.h" \\X// BalooLama on IRC! #anime! #Amiga #nin From slaw@cci.com Wed Aug 10 13:27:04 EDT 1994 Article: 12316 of comp.sys.amiga.audio Newsgroups: comp.sys.amiga.audio Path: sunsrvr6!slaw From: slaw@cci.com (Scott Lawrence) Subject: Re: More on Dolby Encoding -- Phase Shift explanation... Message-ID: Sender: root@sunsrvr6.cci.com (Operator) Organization: Northern Telecom, Network Application Systems References: <3216fh$ieb@prime.mdata.fi> Date: Wed, 10 Aug 1994 14:51:00 GMT In article <3216fh$ieb@prime.mdata.fi>, Pasi Ilola wrote: >Scott Lawrence (slaw@cci.com) wrote: > >: While at lunch, I realized how to do the +90/-90 degree Phase shift!!! It's >: just so simple too! I asked a friend how to do phase shifts, and i was being >: really sketchy for no good reason, and i had said "I know how to do a 180' >: phase shift -- just invert the sample." to which he responded "Yeah, but that's >: just a special example"... that got me thinking, and i now know how to do it. >: It's all in my head, so bear with me... converting this to words and ascii >: graphics is gonna be interesting... > >I wonder how they manage all of the surround encoding in PC demos, for >example: Future Crew seems to be using ready-made surround samples they >didn't encode themselves... Quite possible. although they could be encoding and mixing the sound samples if they wanted to. > and do the Amiga DasModPlayer, PS3M etc. >actually do anything even remotely Dolby Surround? if you make them, they can be in Dolby Surround. Woody, whose e-mail i reposted about doing a _real_ phase shift, with trig functions and all, experimented with it in MED, and got very good results. He could have used any tracker, but (like me) he prefers MED. (No flames please...) Anyway.. What he did was.. in channels 0 put in a sound sample, and channel 1, put in it's inverse. (inverse being the inverted sound sample, or a 180' phase shift. 127 -> -126 etc...) then with a different sound sample, put it in both channels 2 and 3. channels 0 and 1 become the surround channel, and 2 and 3 become the center channel. (0 and 3 being left, and 1&2 being right) so for the "Channel Check" you hear on the end of Movies on laserdisc, do this: in this channel put this voice 0 "Channel Check" 0 "Left Channel, Left Channel" 1 "Right Channel, Right Channel" 0 & 1 "Center Channel, Center Channel" 0 norm, 1 inv "Surround Channel, Surround CHannel" gee, I love that test... ^_^ -J -- Scott "Jerry" Lawrence __ Amiga: We do more with 7.16 Mhz slaw@cci.com, jerry@csh.rit.edu /// than most do all day http://www.csh.rit.edu/~jerry/ __ /// ----------------------------------- #include "disclaimer.h" \\X// BalooLama on IRC! #anime! #Amiga #nin From essl@fstgds06.tu-graz.ac.at Wed Aug 17 21:35:31 EDT 1994 Article: 12391 of comp.sys.amiga.audio Path: sunsrvr6!rit!rochester!cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!news.duke.edu!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!EU.net!Austria.EU.net!newsfeed.ACO.net!fstgds15.tu-graz.ac.at!fstgds06!essl From: essl@fstgds06.tu-graz.ac.at (Georg Essl) Newsgroups: comp.sys.amiga.audio Subject: Re: More on Dolby Encoding -- Phase Shift explanation... Date: 11 Aug 1994 21:28:16 GMT Organization: Graz University of Technology, Austria Lines: 90 Message-ID: <32e55g$qv0@fstgds15.tu-graz.ac.at> References: NNTP-Posting-Host: fstgds06.tu-graz.ac.at X-Newsreader: TIN [version 1.2 PL1] Scott Lawrence (slaw@cci.com) wrote: : While at lunch, I realized how to do the +90/-90 degree Phase shift!!! It's [..] : Now, how do we do this? It's easy. Think of a specific sample as being a : marble in a track with rubber bands at either end.. (+127 & -127, 0 in the : middle) so that if you were to throw the ball to one end, (up to 127) it would : bounce back to the other end. Say the ball is smart. If you give it a force : of 10, it will only move 10 units in the direction you pushed it to. Let's : use Positive as being towards 127, and negative as being towards -127. So If : you were to push this marble from 0 with a force of -30, it would be at -30. : By using the first two examples above, the force needed to convert a sample : to be it's inverse, or 180' phase shift would be 255. Start the marble at 0, : push with a force of +255 , it would move +127 bounce off the end, then go : -127 back the other way, ending in 0. if it were to start at 127, +255 would : make it bounce immediately, then go 255 back in the negative direction, : causing it to stop in -127. Understand this? good. So, if we were to take : this one step further, a 90' phase shift would need half the force than that : of a 180' phase shift, or a force of 127. Use the same method with this : on consecutive samples, with a +90 shift, then -90 shift, add them together i : and they cancel. Why would you want to do this? I have no clue, but it's : that reasoning that keeps background sounds out of the center channel. : So that +90'/-90' phase shift is not as elusive as once i thought.. : The only problem now is that i think sound samples may be logarithmic, as : that's how they are in .au format on this Sparc... that may fix some problems, : like a perfect sine wave, with a 90' shift would, instead of being nice gentle : curves, would be a curve to a point at max volume, then a curve back down to : zero, and a curve down to min, etc... : __ __ ___ : / \ / \ / \__ __/\__ __/\ : \__/ \__/ etc... == yields ==> \/ \/ etc.. : Not sure how to handle this... i was never good at logs... : Constants: : for a 180' phase shift, the constant is 255. : for a 90' phase shift, the constant is 127. : etc... it is linear. This post got me thinking if it is true what you describe here. I'm not quite sure if I really got how you operate the constant for a given key shift on a sample-point. Lets take the constant of 127 as an example. Does the algorithm look like this: direction = add 1 Look if a boundary is reached (+/-127) if yes swap direction (add to sub or sub to add) if direction is add add one to sample-point else sub one to sample-point decrease constant if constant not zero repeat at 1 If this is the algoritm I got the following problems: This alorithm does obviously not work with sounds-samples which have a constant offset (the a0 in the cosine-Fourier-Series [a0+a1*cos t +a2*cos 2*t ...] is not 0). This can be proofed using a simple example: You got a sample having an a0 of 20 and you want to do a phase-shift using the constant of -20 after proceeding the above algorithm you will end up with the sound-sample having the same phase but no a0. Only samples which do not swing in the full range of +/-127 can have a non-zero a0 without losing information. So the problems also occures if we think vice versa.. we got a sample not using the full range and add a small "force" ask my algoritm describes. As long as there is no boundary reached there is obviously no phase-shifting at all. I don't really understand the problem with mu-law encoded samples (as it may be used in .au-files.) You have to decode to get the actual sound, phaseshift and encode again... if you want to do this realtime it may be a problem though ;-) Yours Georg Essl -- --- ***************************************************************************** * Name: Georg Essl, Student of Telematik at the Techical University of Graz * * E-Mail: essl@fstgds06.tu-graz.ac.at (G.Essl@ieee.org) * ***************************************************************************** GCS/E/MU -d+ ---p+++ c++ l(+) u++ e* m++(*) s?/? !n h* f(*) !g w+++ t+ r y? pgp-public-key on e-mail-request. From essl@fstgds06.tu-graz.ac.at Wed Aug 17 21:36:08 EDT 1994 Article: 12392 of comp.sys.amiga.audio Path: sunsrvr6!rit!rochester!udel!gatech!howland.reston.ans.net!EU.net!Austria.EU.net!newsfeed.ACO.net!fstgds15.tu-graz.ac.at!fstgds06!essl From: essl@fstgds06.tu-graz.ac.at (Georg Essl) Newsgroups: comp.sys.amiga.audio Subject: Re: Dolby Encoding- More on Phase Shifts Date: 11 Aug 1994 22:20:48 GMT Organization: Graz University of Technology, Austria Lines: 34 Message-ID: <32e880$qv0@fstgds15.tu-graz.ac.at> References: NNTP-Posting-Host: fstgds06.tu-graz.ac.at X-Newsreader: TIN [version 1.2 PL1] Scott Lawrence (slaw@cci.com) wrote: [..] : Take a single sample of a sound (one vertical cross section, one number, that : is, not a collection of these). Take its ARC SINE in degrees. Add your phase : shift to it. Take the SINE of that in degrees, and Poof!! You've phase shifted : it! (Right?) This should correctly phase shift a single sinusoid of any : frequency, I think, so should work on an arbitrary combination of those. *Sigh* I should have read the whole group before posting ;-). I believe this approach sounds much better. For a simple sine-sounds it is obviously true. I was thinking if the assumption that it works with arbitrary waves is true. My first feeling said it can't be true. Just imagine all waves having the same value at a certain time. There exists an infinite number of such waves. Now you phase-shift by an arbitrary phase (angle) by doing arcsine then add and sine. This would give always the same result for all these waves even though the waves may have any values at another time. But phase-shifting will result in another time-value which has (and most probably is) not to be the same for these waves. I guess it should therefore be easy to find a simple example to proof that the method is not true. Anyway I hope you find a simple solution for this problem. Yours Georg Essl -- --- ***************************************************************************** * Name: Georg Essl, Student of Telematik at the Techical University of Graz * * E-Mail: essl@fstgds06.tu-graz.ac.at (G.Essl@ieee.org) * ***************************************************************************** GCS/E/MU -d+ ---p+++ c++ l(+) u++ e* m++(*) s?/? !n h* f(*) !g w+++ t+ r y? pgp-public-key on e-mail-request.