Can I play a DPL2 soundtrack on a DPL1 system?

[Fr4nz]

As the topic says...can i play a movie encoded with a DPL2 encoded soundtrack on my DPL1 system? Would be the rear channel separation correct?

Thanks for any answer!

Oh I have another question: the surround informations, when encoding from ac3 to mp3 via Lame, is always preserved?
In the hydrogenaudio forum some people doubts that Lame at --alt-preset standard preserves phase informations but I always found my encoded soundtrack very good regarding surround effects. These people claim that in order to preserve phase informations you should encode at higher bitrates, like --alt-preset extreme!! :o

[nuked]

yes. There will be no rear separation though. It will sound very close to what a DPL1 encode would sound like on a DPL1 system.

[bleo]

Simple answer: yes. But the rear speakers will sound the same. Also Ls (or Rs) will come out of both rear speakers AND the front left (or right) speaker. Hopefully it will still sound like it came from somewhere left and behind anyway, even DPL2 channel localisation isn't perfect!

I too have doubts about encoding surround matrixed audio. For normal stereo, out of phase audio isn't important (?) so the codecs throw it out with channel coupling, etc. However for surround, out of phase audio is essential, but is usually the first to get thrown out because the codec was tuned for normal stereo. So, I guess increasing the bitrate helps, or you can explicitly disable lossy channel coupling, e.g. Ogg Vorbis q5+, Real Audio Surround codecs,...

[Fr4nz]

I read somewhere that joint stereo in new codecs (like LAME, MPC, OGG, AAC) shouldn't destroy phase informations...let's hope so :)

[Sycho]

if you play a Dolby Surround Prologic II encoded stream, such as a game or movie (this does not aply to "surround2" downmix), on a Dolby Surround system the result will not be the best (both surround channels will be coming from all channels because it is all pasive). If it is played on a Dolby Surround Prologic system the surround left will play back on both the surround and the left channels, and the surround right will play back on both the surround and right channels.

If it is something encoded using the "surround2" downmix, don't worry a bout it, very little of the surround left and right info will leak into the left and right.

[nuked]

"and the surround right will play back on both the surround and right channels."

yes, but this is not so much a problem with incompatibility as just with DPL1 decoder itself. With DPL1 encode and DPL1 decode surround plays in both surround and front also. Yes presumably the surround material in the left and right will have exactly oposite polarity with the DPLI encode, but this does not at all mean the sound even close to cancels in the front as this depends on your precise ear location and especially since you have 2 in diferent places.... If you've ever plugged in one of your 2 mains backwards with a stereo(or even mono) signal, you know you can still very much hear sound.. just kinda hollow sounding. Actually, the DPLII encode could be a little better because at least, although the sound is in both front and back, the front will still have left to right info and will help preserserve the left right separation some, where as with a DPLI encode it is lost entirely. So basically DPLII encode with DPLI decode should sound about as good or I'd argue slightly better than a DPLI encode with DPLI decode so I might even argue there is no need for DPL1 endcodes. But of course as always you should try it and see what you like.

[nuked]

regarding joint stereo,

There is even another mode that will preserve surround even better possibly but at a cost in bits. If forget what they call it now, dual mono maybe?, or is dual mono the more highly correlated mode... anyway one of the modes bassically encodes each channel completely separately. Acording to the docs joint stereo basically just uses this method but only when it deems it needs to, ie when channel correlation is below some threshold I guess. Anyway, what I know about it is essenstially just from the manual.

[bleo]

Yep, I think dual stereo (each channel half total bitrate) or standard stereo (bitrate varies between channels) will disable channel coupling.

Lame joint stereo automatically switches between stereo and Middle/Side depending on channel correlation. You should note that M/S is not explicitly bad for surround audio. Only when it preferentially compresses the side channel which happens to contain our surround channels will it be bad, or 'lossy channel coupling'. This would generally occur at low bitrates.

[Fr4nz]

Read the posts here, it's a very interesting thread: http://www.hydrogenaudio.org/index.php?showtopic=12004

In few words Lame developers said that LAME preserves phase information thanks to its --nssafejoint mode BUT because of its psychoacoustic model it tends to throw away part of the sound that would be inaudible to human ears.So, sounds which are so quiet that would be inaudible to us, are thrown away...but what about if these sounds where phase-shifted (and so encoded in surround)?? :( Anyway for movies encoding this won't be a great problem because rear effects are usually explosions and in general very loud sounds, so Lame won't throw 'em away and Surround systems will shift sounds from front to rear without problems. On the other side there could be problems when you encode DVDs that contain music (like an orchestra), because volume in the front and in the rear channel are very homogeneus and maybe the surround system could encounter some problems to shift the rear sounds. In this case --nsmsfix 1.0 command is the way to go with Lame. It will preserve at best surround sounds thanks to an higher usage of SS frames than the usual. This will augment of about 10kbps the bitrate.

[bleo]

Very interesting thread at HA :)

I didn't know about the lame --nsmsfix 1.0 switch. From what I gather it biases joint stereo to L/R mode? So I agree, this should be better for DPL material :)

[Fr4nz]

Yes Exactly. It makes more use of SS frames instead of MS ones...this should give a quality boost to surround tracks if you encounter problems with them.

[nuked]

hmm... seems there are 2 issues. One is how much time is speant in l+r/l-r (M/S) vs how much in L/R mode. The other is when in M/S mode, how many bits are given to which signal. I guess from the previous post that this switch only affects the second deciscion and not the first. Actually it's not clear to me that L/R is particularly advantageous if the second descion is made "well" but then that's kind of a diferent aspect of what bleo already said.. if both have lots of bits there's no problem.
Anyway, at some point it becomes arguing about how to a make a very imperfect system slightly less imperfect. DPL has large inaccuracies anyway, especially in music (where this problem is said to be worse) and especially when front and back channels both have sound, the main requirement for lame to have a problem. As the post mentions at the end when back is quite and front is loud or vice versa, DPLII is gonna steer anyway. DPLII is kind of a blind sledge hammer solution in the first place. It assumes, well, since the sound is more from here than there and since we know the encoding by definition leaks across channels, there is a likelyhood that the signal should be steered to here and silenced there, so that's what we'll do. On the other hand... maybe it just really was loud here and quite there...especialy in music, but then that's impossible to know. I would guess that dolby may be biased toward steering to the back more than the front since sound ALWAYS leaks into the front but only leaks into the back if the front signal was not originally mono-like. So maybe half the time dolby would not have already caused this problem quite as badly as lame causes it. Bottom line, sounds like the argument is on the level of roughly 1/4 the error already inherent in DPLII(and even at that only for certain frequencies). I have been pretty happy with phase reproduction of lame in standard mode, but then I use high bit rates.. the all purpose cure for almost every problem but storage space. :)

edit: by the way, I should not say back always leaks to front without saying really waht I mean is in DPLI decode it does.. so when I say steering I mean relative to DPLI which realy is an arbitrary benchmark. DPLI could have used M for front and S for back for instance, but chose to include L and R in front and S for back thus maintaining left to right imaging in half the speakers and maintaining front to back imaging but with always at least half of it leaking to the front... 2 signals is only 2 signals. steering just lets you change the comprimising you want to make on the fly based on some asumption about teh likelyhood of where it came from.. but not the actual knowledge of where it came from.