QAM is different from bit-rate. In fact, 64 QAM is technically capable of delivering a higher bit-rate than 16 QAM. It's just that the broadcasters decide to use the extra bandwidth to squeeze in more channels rather than to increase their bit rate. (64 QAM is also more prone to interference than 16 QAM.)
I have tested this version by downloading a > 6Gb recording off the Hummy and it works perfectly. This version also fixes problems with programme names and EPG data. See some test screenshots here, here and here.
In this session I transfered 20Gb of recordings in 44 mins. Which is a 7Mb/s or 62Mbit/s throughput.
I would also like to say Thanks , I've successfully transferred 5Gb files with 0.871, read them into VideoReDo did a Quickstreem fix and No Errors, lovely.
A 5Gb program transfer's in 12 minutes on my system which beats Elinker by hours literally and is error free.
Thanks for the feedback. Glad someone else other than I and phew are getting the same throughput...
5Gb in 12 minutes is 7Mb/s or 56Mbit/s...
(My figures above should really be 7.7Mb/s and this one is 7.1Mb/s - in case anyone is taking notes )
In the version of the tool I tried first (see post somewhere below) I transfered Panic Room (2.5GB file) in a shade under 4 minutes. So there is possibilities to get faster transfer rates depending on other factors perhaps. This was done with a an IDE to usb connector and attaching to my USB port on the laptop, rather than fitting the humax drive to a desktop PC motherboard
In the version of the tool I tried first (see post somewhere below) I transfered Panic Room (2.5GB file) in a shade under 4 minutes. So there is possibilities to get faster transfer rates depending on other factors perhaps. This was done with a an IDE to usb connector and attaching to my USB port on the laptop, rather than fitting the humax drive to a desktop PC motherboard
2.5Gb in 4 mins is again 7.1Mb/s which is 56Mbit/s.
Apart from connections, other factors includes what file sizes and how many are being transfered (and what HDD is connected!).
Just transfered about 27Gb (of smaller files) off the 160Gb HDD directly connected to the PC in 30mins. See here. (Previous transfer speeds was from a IDE->USB widget connect to the Hummy's HDD and with larger, > 4Gb files.)
This gives 14Mb/s which is 117Mbit/s.... nice!
In practical use any speeds between 30Mbit/s to 117Mbit/s is far more useful than the Hummy's own transfer speed...
Not that I'm obsessed by speeds but keithatrochdale was only acheiving 17Mbit/s (see above post #193) (at this rate might as well revert back to eLinker!) which is way too slow. Have you had any more luck since then, Keith?
2.5Gb in 4 mins is again 7.1Mb/s which is 56Mbit/s.
Mine was more like 10.5MB/s or 84Mbits/s. Not important but I agree its interesting to see what speeds are possible and therefore potentially how valuable the tool is for certain things.
Just goes to show that even removing the Humax inflicted bottle necks the theoretical maximum transfer rate of USB 2.0 Hi Speed (480Mbit/s) is just that - theoretical!
I don't know where that 480Mbit/s figure comes from (I know, from the USB2.0 standard - I mean how they made up that number!) because even with their test figures they can only and practically achieve a max of 288 to 320Mbit/s! All I can say is that sort of figure is raw read/writes and the data is probably trash out...
Perhaps Cliff or Nigel et all can input, but how does this compare with the same process using tools for other PVRs like toppy/Fusion direct hard disk connection downloads? Are they hitting a certain transfer rate maximum too over Hi Speed USB 2.0 connections and IDE to IDE PC connections?
Next time I've got my Fusion drive hooked up I'll time some transfers but at the end of the day I don't believe that the transfer rate is really any different than if you connected two "normal" Windows drives to a PC and just did "copy c:\video.mpg d:" (this is with IDE connections, not USB, which [IDE] is the way I do it). So it's going to be down to the speed of the UDMA support in your PC's chipset and BIOS I think.
Just as a quick test, on my work PC here I have a 806,768,640 byte .MPG file on one drive that I just copied to another drive. This took 104 seconds. So that's 775,739 bytes per second or 6,205,912 bits per second.
I won't try quoting that as MB or GB cos then we'll have to decide whether we are talking about MegaBytes (MB), MebiBytes (MiB), MegaBits (Mb), MebiBits (Mib), GigaBytes (GB), GibiBytes (GiB), GigaBits (Gb) or GibiBits (Gib) which always gets VERY messy !!!
Can we see you working please I can't see how you possibly get those numbers.
I said that 775,739 bytes were transferred in one second. If you consider a MegaByte to be 1000000 bytes then that is 0.775739 MB/s. If you consider a MegaByte to be 1048576 bytes (that we're now told should be called a MebiByte and denoted MiB) then it is 0.73980236 MiB/s
To convert MegaBytes/s or MebiBytes/s to MegaBits/s or MebiBits/s I don't think anyone can argue that the ONLY way to make that conversion is to multiply by 8 (because there are ALWAYS 8 bits in a byte!!). So that gives me 6.205912 Mb/s or 5.91841888 Mib/s
You also quote Mb/s and Mbit/s - aren't these the very same thing? Remember it is ALWAYS "b = bits", "B = bytes"
(in fact it tickled me the other day to be the first person in our company that's been making Sky + PVRs for several years to spot that alll the box labelleing says 80Gb rather than the 80GB that it should, thus suggesting that the user of Sky+ only gets 10GB of storage!!!)
Let's see. Mb/s = MegaBytes per second, Mbit/s = Megabits per second.
Yes my terminology is probably wrong and is confusing you... (I use Mbit/s in term of network speeds, i.e bitrates... but you are right, MegaBytes per Second should be MB/s)
Just as a quick test, on my work PC here I have a 806,768,640 byte .MPG file on one drive that I just copied to another drive. This took 104 seconds.
Cliff
You said 806,768,640 bytes copied over in 104 sec.
806768640 bytes in 104 sec
769 Mb (divide by 1024 to get Kb and again to get Mb) in 104 secs
769Mb divided by 104s = 7.4Mb/s which is (times 8) 59Mbit/s (8 bits in a byte)
So that's 775,739 bytes per second or 6,205,912 bits per second.
Ah, got you, my error was the dropped 0 on 775,739 which should have read 7,757,390 bytes/second - which is 7.75739 MB/s or the 7.398024339 MiB/s that you calculated. Then multiplying by 8 gives 59.18419471 Mib/s or 62.05912 Mb/s
Not that I'm obsessed by speeds but keithatrochdale was only acheiving 17Mbit/s (see above post #193) (at this rate might as well revert back to eLinker!) which is way too slow. Have you had any more luck since then, Keith?
Not yet, I don't see why my speeds are so slow - but transfer was impossable with e-linker so this is progress.
There are products that are about to be released that should give the hummy USB port UWB wireless connection to a PC hopefully for use with elinker. But if you are wanting to considerably ramp up the speed of transfer by avoiding going through the hummy USB port and instead using direct access to the hummy disk using tools like Phews, what are the options if any at all? I know you can buy wireless 'network' devices now where you can connect at hard disk to them and they are available to PC on the wireless network. Is it therefore true that the hummy hard drive can be conected to similar device kept say behind the hummy permanantly and on the PC a tool like Phews be used?
There are products that are about to be released that should give the hummy USB port UWB wireless connection to a PC hopefully for use with elinker. But if you are wanting to considerably ramp up the speed of transfer by avoiding going through the hummy USB port and instead using direct access to the hummy disk using tools like Phews, what are the options if any at all? I know you can buy wireless 'network' devices now where you can connect at hard disk to them and they are available to PC on the wireless network. Is it therefore true that the hummy hard drive can be conected to similar device kept say behind the hummy permanantly and on the PC a tool like Phews be used?
My initial thought is that it should work as long as the PC sees the Hummy's HDD as a physical 'disk' and not a virtual device that the 'wireless device' driver might create.
But the proof is in the pudding... we need someone with the wireless kit to make some tests...
Comments
Multiplex 1
Operated by the BBC; broadcasts nationwide in 16QAM mode at 18 megabits/second
Multiplex 2
Operated by Digital 3&4 (an ITV/Channel 4 consortium); broadcasts nationwide in 64QAM mode at 24 megabits/second
The number of channels carried within the datastream is also important and that can be seen on the link for the 16 and 64 QAM MUXs .
I have tested this version by downloading a > 6Gb recording off the Hummy and it works perfectly. This version also fixes problems with programme names and EPG data. See some test screenshots here, here and here.
In this session I transfered 20Gb of recordings in 44 mins. Which is a 7Mb/s or 62Mbit/s throughput.
A 5Gb program transfer's in 12 minutes on my system which beats Elinker by hours literally and is error free.
Thanks Again
Richard.
Thanks for the feedback. Glad someone else other than I and phew are getting the same throughput...
5Gb in 12 minutes is 7Mb/s or 56Mbit/s...
(My figures above should really be 7.7Mb/s and this one is 7.1Mb/s - in case anyone is taking notes
Hopefully onwards and upwards! Watch this space!
In the version of the tool I tried first (see post somewhere below) I transfered Panic Room (2.5GB file) in a shade under 4 minutes. So there is possibilities to get faster transfer rates depending on other factors perhaps. This was done with a an IDE to usb connector and attaching to my USB port on the laptop, rather than fitting the humax drive to a desktop PC motherboard
2.5Gb in 4 mins is again 7.1Mb/s which is 56Mbit/s.
Apart from connections, other factors includes what file sizes and how many are being transfered (and what HDD is connected!).
Just transfered about 27Gb (of smaller files) off the 160Gb HDD directly connected to the PC in 30mins. See here. (Previous transfer speeds was from a IDE->USB widget connect to the Hummy's HDD and with larger, > 4Gb files.)
This gives 14Mb/s which is 117Mbit/s.... nice!
In practical use any speeds between 30Mbit/s to 117Mbit/s is far more useful than the Hummy's own transfer speed...
Not that I'm obsessed by speeds
However in your last post you also said of my transfer rate:
Mine was more like 10.5MB/s or 84Mbits/s. Not important but I agree its interesting to see what speeds are possible and therefore potentially how valuable the tool is for certain things.
Just goes to show that even removing the Humax inflicted bottle necks the theoretical maximum transfer rate of USB 2.0 Hi Speed (480Mbit/s) is just that - theoretical!
I don't know where that 480Mbit/s figure comes from (I know, from the USB2.0 standard - I mean how they made up that number!) because even with their test figures they can only and practically achieve a max of 288 to 320Mbit/s! All I can say is that sort of figure is raw read/writes and the data is probably trash out...
http://www.everythingusb.com/usb2/faq.htm
Just as a quick test, on my work PC here I have a 806,768,640 byte .MPG file on one drive that I just copied to another drive. This took 104 seconds. So that's 775,739 bytes per second or 6,205,912 bits per second.
I won't try quoting that as MB or GB cos then we'll have to decide whether we are talking about MegaBytes (MB), MebiBytes (MiB), MegaBits (Mb), MebiBits (Mib), GigaBytes (GB), GibiBytes (GiB), GigaBits (Gb) or GibiBits (Gib) which always gets VERY messy !!!
Cliff
IDE, EIDE, Fast ATA, Fast ATA-2, Ultra ATA (Fast ATA/33), Ultra ATA/66, Ultra ATA/100!!
The numbers in the latter standards indicates Mbit/s... So achieving around 64Mbit/s looks like Ultra ATA/66...
So how did I get 117Mbit/s? Deja Vu? Are my numbers/calculations going wobbly again ...
I said that 775,739 bytes were transferred in one second. If you consider a MegaByte to be 1000000 bytes then that is 0.775739 MB/s. If you consider a MegaByte to be 1048576 bytes (that we're now told should be called a MebiByte and denoted MiB) then it is 0.73980236 MiB/s
To convert MegaBytes/s or MebiBytes/s to MegaBits/s or MebiBits/s I don't think anyone can argue that the ONLY way to make that conversion is to multiply by 8 (because there are ALWAYS 8 bits in a byte!!). So that gives me 6.205912 Mb/s or 5.91841888 Mib/s
You also quote Mb/s and Mbit/s - aren't these the very same thing? Remember it is ALWAYS "b = bits", "B = bytes"
(in fact it tickled me the other day to be the first person in our company that's been making Sky + PVRs for several years to spot that alll the box labelleing says 80Gb rather than the 80GB that it should, thus suggesting that the user of Sky+ only gets 10GB of storage!!!)
Cliff
Yes my terminology is probably wrong and is confusing you... (I use Mbit/s in term of network speeds, i.e bitrates... but you are right, MegaBytes per Second should be MB/s)
You said 806,768,640 bytes copied over in 104 sec.
806768640 bytes in 104 sec
769 Mb (divide by 1024 to get Kb and again to get Mb) in 104 secs
769Mb divided by 104s = 7.4Mb/s which is (times 8) 59Mbit/s (8 bits in a byte)
Cliff
Not yet, I don't see why my speeds are so slow - but transfer was impossable with e-linker so this is progress.
May have time to play tomorrow, so stand by!
Are you using a Laptop?
But the proof is in the pudding... we need someone with the wireless kit to make some tests...
Yup, a few
No
Whatever bits I bought at the time.