What's the use of a 192 kHz sample rate?
in [DSP]
|
Prev: Is 44.1 KHz sample-rate enough to cover the entire human hearingrange?
Next: Newbie to DSP - Phase shift detection
From: rajesh on 7 May 2008 00:35 On May 7, 8:53 am, isw <i...(a)witzend.com> wrote: > In article > <b86829fe-0a50-4bc5-8c2b-4274cfff7...(a)q27g2000prf.googlegroups.com>, > > > > rajesh <getrajes...(a)gmail.com> wrote: > > On May 6, 9:53 am, rajesh <getrajes...(a)gmail.com> wrote: > > > On May 5, 10:33 pm, dpierce.cartchunk....(a)gmail.com wrote: > > > > > On May 5, 10:09 am, rajesh <getrajes...(a)gmail.com> wrote: > > > > > > On May 5, 7:05 pm, Oli Charlesworth <ca...(a)olifilth.co.uk> wrote: > > > > > > If we can, then of course a higher sampling rate will sound better. > > > > > > But that goes against the premises of the OP, and is nothing to do > > > > > > with the ECC or interpolation that you've been going on about! > > > > > > > -- > > > > > > Oli > > > > > > I said we cant percieve, but i didnt say they arent there.. > > > > > Again, true but irrelevant. > > > > > > i will continue the dicussion on ECC tomorrow. > > > > > Hopefully, you will be much better prepared. > > > > > As a hint: the issue of proper sampling vs bandwidth > > > > is a topic COMPLETELY separate from ECC. You > > > > might want to keep that in mind during your preparations. > > > > take for example h.264 video > > > Apart from having many sophisticated techniques it also > > > recommends simple one like repeating packets. > > > Correction its not packets , its slices > > Slice repeat is not for handling errors; it's an efficient encoding > technique. Instead of sending all the data a second time whwnever two > slices are nearly identical (and that happens fairly often), just say > "remember that slice I just sent you? Well, use it again, but make these > minor changes to it." > > Isaac I didnt get how repetition can be used for efficient encoding?
From: rajesh on 7 May 2008 01:48 On May 7, 9:35 am, rajesh <getrajes...(a)gmail.com> wrote: > On May 7, 8:53 am, isw <i...(a)witzend.com> wrote: > > > > > In article > > <b86829fe-0a50-4bc5-8c2b-4274cfff7...(a)q27g2000prf.googlegroups.com>, > > > rajesh <getrajes...(a)gmail.com> wrote: > > > On May 6, 9:53 am, rajesh <getrajes...(a)gmail.com> wrote: > > > > On May 5, 10:33 pm, dpierce.cartchunk....(a)gmail.com wrote: > > > > > > On May 5, 10:09 am, rajesh <getrajes...(a)gmail.com> wrote: > > > > > > > On May 5, 7:05 pm, Oli Charlesworth <ca...(a)olifilth.co.uk> wrote: > > > > > > > If we can, then of course a higher sampling rate will sound better. > > > > > > > But that goes against the premises of the OP, and is nothing to do > > > > > > > with the ECC or interpolation that you've been going on about! > > > > > > > > -- > > > > > > > Oli > > > > > > > I said we cant percieve, but i didnt say they arent there.. > > > > > > Again, true but irrelevant. > > > > > > > i will continue the dicussion on ECC tomorrow. > > > > > > Hopefully, you will be much better prepared. > > > > > > As a hint: the issue of proper sampling vs bandwidth > > > > > is a topic COMPLETELY separate from ECC. You > > > > > might want to keep that in mind during your preparations. > > > > > take for example h.264 video > > > > Apart from having many sophisticated techniques it also > > > > recommends simple one like repeating packets. > > > > Correction its not packets , its slices > > > Slice repeat is not for handling errors; it's an efficient encoding > > technique. Instead of sending all the data a second time whwnever two > > slices are nearly identical (and that happens fairly often), just say > > "remember that slice I just sent you? Well, use it again, but make these > > minor changes to it." > > > Isaac > > I didnt get how repetition can be used for efficient encoding? I think a new thread has to be started on H.264. As this thread appears to be very dangerous.
From: Don Pearce on 7 May 2008 02:00 On Tue, 6 May 2008 21:35:17 -0700 (PDT), rajesh <getrajeshin(a)gmail.com> wrote: >On May 7, 8:53 am, isw <i...(a)witzend.com> wrote: >> In article >> <b86829fe-0a50-4bc5-8c2b-4274cfff7...(a)q27g2000prf.googlegroups.com>, >> >> >> >> rajesh <getrajes...(a)gmail.com> wrote: >> > On May 6, 9:53 am, rajesh <getrajes...(a)gmail.com> wrote: >> > > On May 5, 10:33 pm, dpierce.cartchunk....(a)gmail.com wrote: >> >> > > > On May 5, 10:09 am, rajesh <getrajes...(a)gmail.com> wrote: >> >> > > > > On May 5, 7:05 pm, Oli Charlesworth <ca...(a)olifilth.co.uk> wrote: >> > > > > > If we can, then of course a higher sampling rate will sound better. >> > > > > > But that goes against the premises of the OP, and is nothing to do >> > > > > > with the ECC or interpolation that you've been going on about! >> >> > > > > > -- >> > > > > > Oli >> >> > > > > I said we cant percieve, but i didnt say they arent there.. >> >> > > > Again, true but irrelevant. >> >> > > > > i will continue the dicussion on ECC tomorrow. >> >> > > > Hopefully, you will be much better prepared. >> >> > > > As a hint: the issue of proper sampling vs bandwidth >> > > > is a topic COMPLETELY separate from ECC. You >> > > > might want to keep that in mind during your preparations. >> >> > > take for example h.264 video >> > > Apart from having many sophisticated techniques it also >> > > recommends simple one like repeating packets. >> >> > Correction its not packets , its slices >> >> Slice repeat is not for handling errors; it's an efficient encoding >> technique. Instead of sending all the data a second time whwnever two >> slices are nearly identical (and that happens fairly often), just say >> "remember that slice I just sent you? Well, use it again, but make these >> minor changes to it." >> >> Isaac > >I didnt get how repetition can be used for efficient encoding? You have that backwards. The point is that you don't repeat slices. You send a code which says "This next bit is almost the same as that last bit, so I will not send it again, just use what you got last time, with these minor changes". Imagine you had sent a book electronically to your publisher, but decided to change the name of one of the characters. You wouldn't resend him the whole book - you'd just tell him what the new name was and let him make the changes in the copy he already has. That is the efficient way to do it. d -- Pearce Consulting http://www.pearce.uk.com
From: rajesh on 7 May 2008 02:12 On May 7, 11:00 am, nos...(a)nospam.com (Don Pearce) wrote: > On Tue, 6 May 2008 21:35:17 -0700 (PDT), rajesh > > > > <getrajes...(a)gmail.com> wrote: > >On May 7, 8:53 am, isw <i...(a)witzend.com> wrote: > >> In article > >> <b86829fe-0a50-4bc5-8c2b-4274cfff7...(a)q27g2000prf.googlegroups.com>, > > >> rajesh <getrajes...(a)gmail.com> wrote: > >> > On May 6, 9:53 am, rajesh <getrajes...(a)gmail.com> wrote: > >> > > On May 5, 10:33 pm, dpierce.cartchunk....(a)gmail.com wrote: > > >> > > > On May 5, 10:09 am, rajesh <getrajes...(a)gmail.com> wrote: > > >> > > > > On May 5, 7:05 pm, Oli Charlesworth <ca...(a)olifilth.co.uk> wrote: > >> > > > > > If we can, then of course a higher sampling rate will sound better. > >> > > > > > But that goes against the premises of the OP, and is nothing to do > >> > > > > > with the ECC or interpolation that you've been going on about! > > >> > > > > > -- > >> > > > > > Oli > > >> > > > > I said we cant percieve, but i didnt say they arent there.. > > >> > > > Again, true but irrelevant. > > >> > > > > i will continue the dicussion on ECC tomorrow. > > >> > > > Hopefully, you will be much better prepared. > > >> > > > As a hint: the issue of proper sampling vs bandwidth > >> > > > is a topic COMPLETELY separate from ECC. You > >> > > > might want to keep that in mind during your preparations. > > >> > > take for example h.264 video > >> > > Apart from having many sophisticated techniques it also > >> > > recommends simple one like repeating packets. > > >> > Correction its not packets , its slices > > >> Slice repeat is not for handling errors; it's an efficient encoding > >> technique. Instead of sending all the data a second time whwnever two > >> slices are nearly identical (and that happens fairly often), just say > >> "remember that slice I just sent you? Well, use it again, but make these > >> minor changes to it." > > >> Isaac > > >I didnt get how repetition can be used for efficient encoding? > > You have that backwards. The point is that you don't repeat slices. > You send a code which says "This next bit is almost the same as that > last bit, so I will not send it again, just use what you got last > time, with these minor changes". > > Imagine you had sent a book electronically to your publisher, but > decided to change the name of one of the characters. You wouldn't > resend him the whole book - you'd just tell him what the new name was > and let him make the changes in the copy he already has. That is the > efficient way to do it. > > d > -- > Pearce Consultinghttp://www.pearce.uk.com What you have mentioned is not repetition, its a different issue. There is another context where they duplicate slices and transmit.
From: Don Pearce on 7 May 2008 02:18
On Tue, 6 May 2008 23:12:53 -0700 (PDT), rajesh <getrajeshin(a)gmail.com> wrote: >What you have mentioned is not repetition, its a different issue. > >There is another context where they duplicate slices and transmit. > Do you mean like the RWIN parameter in ADSL? A packet is sent, received and examined. If there is an error, that entire packet is sent again; a common size would be about 1500 bytes. You choose the exact number of bytes in that packet according to how reliable or error-prone the transmission path is. What you don't do is send the packet twice, just in case there might be an error. d -- Pearce Consulting http://www.pearce.uk.com |