Topic: MC9 and 1394 (Read 6893 times)

Autoelph · « **on:** February 07, 2003, 07:09:41 am »

The write times to these drives in MC9 is unusually slow. When tagging and saving images in the file, other progs are quite a bit faster on these drives. And MC9 writes very quickly to my IDE. Can anyone shed any light on why MC9 might have a problem with a 1394 interface?

TIA,

Michael

KingSparta · « **Reply #1 on:** February 07, 2003, 07:27:58 am »

Smaller\Slower Pipe Line?

Detached\External Drives Normaly Also Use Slower Dives Like About 5000rpm Vrs an internal 7200rpm

I think MC9 does a much better job than it did in MJ8 when doing any taging.

why you feel other programs are faster i would not know why this would be.

Autoelph · « **Reply #2 on:** February 07, 2003, 07:35:26 am »

This is a 400MB per sec protocol, works great in capturing DV. Plus as I said, they are quick and responsive using other programs, just not MC9. ?

JimH · « **Reply #3 on:** February 07, 2003, 07:50:47 am »

What brand and model of drive(s)?

Any other software fiddling around with the port? That kind of problem is growing.

Autoelph · « **Reply #4 on:** February 07, 2003, 08:16:34 am »

It's a Maxtor 1394 with two Maxtor 80gig drives attached. I once used these for DV, but now these are dedicated to MP3's only on a machine that does nothing but MC and some light web browsing. Nothing else has access to the ports, just the drives. Also, if the detail helps, the drives are attached to their own respective port, they are not chained.

Thanks again!

UdoS · « **Reply #5 on:** February 07, 2003, 10:18:27 am »

The SCSI-Bruner is still not recgnized.

Udo

Media Center Registered 9.0.108 -- C:\Program Files\J River\Media Center\

Microsoft Windows 2000 Workstation 5.0 Service Pack 3 (Build 2195)
Intel Pentium III 849 MHz MMX / Memory: Total - 392 MB, Free - 204 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.81 / Shlwapi.dll: 6.00.2800.1106
Shell32.dll: 5.00.3502.6144 / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive H: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Drive I: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: No / Calc replay gain: No / Copy volume: 32767
Eject after ripping: No / Play sound after ripping: No

Burning / No burners found.
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: No
Use playback settings: No / Normalization: None

Autoelph · « **Reply #6 on:** February 08, 2003, 03:44:53 am »

Update:

I did my own time trials on this, using the Smashing Pumpkins "Siamese Dream" album, I stripped the tags clean and had MC go against Tag&Rename for speed access to the 1394 drive. T&R wrote the tags including cover art in 19 seconds

, MC9 took 71 seconds

. For some odd reason, it takes nearly 4x longer for MC to access these drives, at least in writing tags. Maybe there is something in the scheme that MC uses that slows the pipeline of info...I don't know, but I sure wish MC was quicker. I realize there are many other pressing and more urgent issues with MC9 right now, but I appreciate any assistance you can offer.

Thanks,

Michael

Autoelph · « **Reply #7 on:** February 24, 2003, 12:20:43 pm »

Bump...?

xen-uno · « **Reply #8 on:** February 24, 2003, 04:52:33 pm »

It's kind of odd that you get such widely different benchmarks. IEEE 1394 (FireWire) is a serial SCSI variant, and as such, both programs should use the system for Reads/Writes. MC must be doing some non-standard API calls OR it's verifying the file OR it's not efficiently writing the file. A sustained 40 to 50 MB/s (FireWire spec) is much faster than what a typical uncached drive can put out...so there is no bottleneck there.

10^-27

KingSparta · « **Reply #9 on:** February 25, 2003, 01:26:33 am »

CPU Speed? And Motherboard?

Autoelph · « **Reply #10 on:** February 25, 2003, 03:59:22 am »

Quote

CPU Speed? And Motherboard?

Shouldn't matter, see test results above, MC9 is 4x slower than Tag&Rename doing the exact same functions. It has to be as Xen-uno said "...it's (MC9) not efficiently writing the file". There is something in the tag writing scheme MC9 uses that slows this process down to a crawl. In a similar test, MC9 vs T&R on my IDE drive is nearly identical writing speed. I wonder if anyone has noticed this using a USB drive?

KingSparta · « **Reply #11 on:** February 25, 2003, 09:55:49 am »

maybe i should test this with my firewire drives with MC and tag and rename.

but i really don't see the problem right now.

I updated 190 files the other day and it was rather quick

Autoelph · « **Reply #12 on:** February 25, 2003, 10:36:31 am »

Please do a test, I need to find this traffic jam somehow, but it's gotta be MC related.

KingSparta · « **Reply #13 on:** February 25, 2003, 10:40:23 am »

Here is something

Tested a ID3v2 write of 23,182 MP3 files

It took 1986 seconds (mins 30:06 secs)

I calculate that at 0.085669 seconds per file

Written to a Firewire Drive

Autoelph · « **Reply #14 on:** February 25, 2003, 10:47:28 am »

My test came out to 5.4615384165 seconds per file.

KingSparta · « **Reply #15 on:** February 25, 2003, 10:50:11 am »

My system specs

Media Center Registered 9.0.120 -- C:\Program Files\J River\Media Center\

Microsoft Windows XP Workstation 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 1798 MHz MMX / Memory: Total - 522 MB, Free - 182 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1106 (xpsp1.020828-1920)
Shell32.dll: 6.00.2800.1145 (xpsp2.021108-1929) / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive D: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: Yes / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: Yes / Play sound after ripping: Yes Soundfile: C:\WINNT\Media\Windows XP Hardware Remove.wav

Burning / Drive D: LITE-ON LTR-40125S Addr: 1:0:0 Speed:40 MaxSpeed:40 Use MJ Engine:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: Yes
Use playback settings: Yes / Normalization: None

Autoelph · « **Reply #16 on:** February 25, 2003, 11:04:14 am »

Ok, first off you've got a P4 1.8 vs my P3 600E, so there's about 3-4 seconds worth of speed alone. But you do have SP1. Still, can't emphasize this enough (sorry) it's MC only. The drives are smokin' doing the exact same function with other progs.

Media Center Registered 9.0.120 -- C:\Program Files\J River\Media Jukebox\

Microsoft Windows XP Workstation 5.1 (Build 2600)
Intel Pentium III 599 MHz MMX / Memory: Total - 261 MB, Free - 96 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpclient.010817-1148 ) / Shlwapi.dll: 6.00.2800.1106
Shell32.dll: 6.00.2600.0000 (xpclient.010817-1148 ) / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive H: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Drive I: Copy mode:ModeBurstBigBuffer CD Type:Auto Read speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: Yes / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: Yes / Play sound after ripping: No

Burning / Drive I: MITSUMI CR-48X8TE Addr: 1:1:0 Speed:16 MaxSpeed:16 Use MJ Engine:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: No
Use playback settings: No / Normalization: None

xen-uno · « **Reply #17 on:** February 25, 2003, 11:52:00 am »

You guys ought to run WinBench (or whatever ZD calls it now...or some other benchmarking prog) on both your local (IDE/SCSI) and serially attached drives...see what kind of numbers you come up with. I'm curious...and so is the rest of the world.

10^-27

JimH · « **Reply #18 on:** February 25, 2003, 12:18:48 pm »

Autoelph,
There's another possibility. That is the way that ID3v2 tags are written.

In some cases, the entire file must be re-written because the tag is placed at the beginning. Example: adding an image to a tag.

Your other program may be set differently or handle this situation differently.

If the tag does not need to be increased in size, the file does not need to be re-written.

It's still possible we're doing something that causes this.

Autoelph · « **Reply #19 on:** February 25, 2003, 12:34:11 pm »

Thanks for the info Jim. Does MC not always rewrite the ID3v2 tags? Or, does MC write ID3v2 tags differently than other mentioned prog?

I do notice slow downs on all tags in MC9 on these drives the first time I write anything to them (change album name, add keywords, etc.) and then the speed improves as I change them again. Always though, when adding images (first time or changing an image later) the tagging crawls (you must be saying this is due to file size changes. Different image, different file size, tag rewritten.)

graham131 · « **Reply #20 on:** February 25, 2003, 02:18:00 pm »

Guys,

I am looking to expand my Storage capabilities by utilising external storage. I have USB2 and Firewire. I am currently looking at the Lacie 500Mb or the Maxtor 250Mb (both support both) It will be interesting to see if you can resolve this Autoelph as I beleive that more and more people will follow this route once internal IDE or PSU capability's fill up!

Just my 2p's worth (sorry I am English - so do not do 2 cents etc)

Graham

xen-uno · « **Reply #21 on:** February 25, 2003, 03:11:23 pm »

OK...

I DL'd and installed WinBench '99 V2 from here (the stripped down 9.5 MB ver)

After installing WB....

1) To select drive go to WinBench>Edit>Test Settings
2) To perform selected test, in the main Functions function select Run and pick Selected from the combo box...from there pick the following: Disk Transfer Rate (DTR), Disk Access Time (DAT), and Disk CPU Utilization (DCU) and eliminate the other tests if present.

DTR & DCU are kind of time consuming (I cut DTR off after it hit the 10 GB mark and estimated the average)

System: 700 MHz PIII sys w/ 386MB RAM & W2k SP3
Conditions: Everything was closed except for WB and a few system tray items (virus soft disabled)

Drive D: => DTR = 25 MB/s; DAT = 6.34 ms; DCU = 1.96 %
D: is a 20 GB 10000 rpm wide SCSI-160 drive

Drive S: => DTR = 25 MB/s; DAT = 13.5 ms; DCU = 1.91 %
S: is a 60 GB 7200 rpm ATA-100 EIDE drive

Doing these tests may help see if there's some major difference between the FireWire & IDE drives on your system.

10^-27

Autoelph · « **Reply #22 on:** February 25, 2003, 05:14:47 pm »

Thanks Xen-uno for the link. My drives don't really need testing though. I know I get flawless DV into my firewire drives. I've captured thousands of hours of DV and never lost a frame, not once. The 1394 chain has been very stable and reliable using many different software\hardware combinations doing mainly high quality & high impact audio\video recording\editing\authoring. The only time I have ever seen a speed "problem" is when tagging with MC, period.

I just wish it was better. I know it was better in very early versions of MC and it was better in MJ8. I'm getting by using T&R, but it's adding unecessary steps to what should be a simple task. It's debatable which path is costing me more time, tagging in MC, or tagging in T&R then importing to MC.

I know lots of people will be going to external, true. Is it an MC issue in the grand sense, or is it an MC issue for me alone? Apparently, this will remain a hanging ? for now.

RemyJ · « **Reply #23 on:** February 25, 2003, 05:32:30 pm »

Quote

This is a 400MB per sec protocol, works great in capturing DV. Plus as I said, they are quick and responsive using other programs, just not MC9. ?

It's 400 megaBITS per second (it's a serial protocol) not megaBYTES. Ignoring protocol overhead, that's about HALF the throughput of a standard ATA/100 controller which is why the Firewire to IDE bridges in the external enclosures are usually ATA/33 or ATA/66 at most.

Capturing a data stream is a lot easier because it's a steady stream of sequential writes. Updating tags is a lot more intensive because it involves reads and writes scattered across the media.

xen-uno · « **Reply #24 on:** February 25, 2003, 07:17:03 pm »

elph...yeah I know they don't. I was just curious to see how your FW drive benchmarked against SCSI/IDE interface drives (25 MB/s on mine).

rem > that's about HALF the throughput of a standard ATA/100 controller

Still a non-factor when doing non-cached reads/writes (which is what is happening when writing files larger than the on-board cache). Assuming 20% overhead, FW is down to 40MB/s, still well over what my very fast SCSI drive can do at the mentioned 25 MB/s.

> why the Firewire to IDE bridges in the external enclosures

Avoid these bridges then, cause IDE/EIDE/ATA does NOT support multitasking/cueing/disconnect/reconnect like the SCSI/FW interface does.

10^-27

Autoelph · « **Reply #25 on:** February 26, 2003, 04:33:05 am »

Xen- I've never benchmarked before, but I will give it a try as it would be interesting to know...

Rem- as far as data read\writes, nothing is more intensive than a\v recording and encoding. I've done 20 tracks of live audio into both my SCSI and FW chains, no problem. I've mixed 54 tracks of audio with intense FX chains across more than half of the tracks, again no problem. I've run stereo mix tracks back into the drive while the main mix is running, np. I seriously doubt that writing a tag in a 4 MB MP3 file is more intense than that. And once more and for the last time, another prog doing the exact same tag write did it 4x faster, so the chain is fine, it's MC.

xen-uno · « **Reply #26 on:** February 26, 2003, 05:37:21 am »

elph...

Found a (much) better benchmarker (Sandra)...go here.

After installing run the File System Benchmark

My results for D: (SCSI-160) & S: (ATA-100)
Buff Read = D: 30 MB/s, S: 26 MB/s
Seq Read = D: 23 MB/s, S: 25 MB/s
Rand Read = D: 7 MB/s, S: 7 MB/s
Buff Write = D: 10 MB/s, S: 18 MB/s
Seq Write = D: 21 MB/s, S: 17 MB/s
Rand Write = D: 6 MB/s, S: 11 MB/s
Ave Access Time = D: 6 ms, S: 7 ms

10^-27

Autoelph · « **Reply #27 on:** February 26, 2003, 10:05:58 am »

xen, here's my FW readings, both 80G drives I have came out identical...not quite your SCSI #'s but closer than I would have thought.

Buffered Read : 23 MB/s
Sequential Read : 23 MB/s
Random Read : 5 MB/s
Buffered Write : 15 MB/s
Sequential Write : 15 MB/s
Random Write : 5 MB/s
Average Access Time : 10 ms (estimated)

And my ATA 100:

Buffered Read : 28 MB/s
Sequential Read : 29 MB/s
Random Read : 7 MB/s
Buffered Write : 19 MB/s
Sequential Write : 19 MB/s
Random Write : 11 MB/s
Average Access Time : 7 ms (estimated)

KingSparta · « **Reply #28 on:** February 26, 2003, 10:35:17 am »

Drive E, 160gig Firewire

Benchmark Breakdown
Buffered Read : 35 MB/s
Sequential Read : 22 MB/s
Random Read : 3810 kB/s
Buffered Write : 25 MB/s
Sequential Write : 21 MB/s
Random Write : 5 MB/s
Average Access Time : 14 ms (estimated)

Drive F, 160gig Firewire
Benchmark Breakdown
Buffered Read : 35 MB/s
Sequential Read : 18 MB/s
Random Read : 5 MB/s
Buffered Write : 25 MB/s
Sequential Write : 18 MB/s
Random Write : 7 MB/s
Average Access Time : 10 ms (estimated)

xen-uno · « **Reply #29 on:** February 26, 2003, 12:39:48 pm »

elph...

Between you, the King, & I...there's not much difference in interface/drive speeds (at least in single tasking instances). As suspected...it's the way MC is writing the file...

If you really want to get down & dirty then copy a 200 MB block of files to a temp directory on both your FW drive and your IDE drive...then do a mass tag edit with MC (or did you try this already?)...then at least your comparing apples to apples.

Sandra's pretty cool, eh? She gives you a ton of info.

10^-27

Autoelph · « **Reply #30 on:** February 26, 2003, 12:48:22 pm »

Yea, a ton of info, took me a while to find the benchmark tests in all those programs!

I did an IDE test, and Tag&Rename matched speed with MC9, both wrote very quickly. I wish I knew why, but my FW and MC have a totally inefficient relationship.

graham131 · « **Reply #31 on:** February 26, 2003, 01:13:08 pm »

I have a question.

The Apple Ipod is firewire - has anyone experienced any slwodowns with this and MC?

Mine is very fast. I know its a different thing all together but its a Firewire Device running on MC.

If you want me to try anything just ask.

Cheers

Autoelph · « **Reply #32 on:** February 26, 2003, 01:38:25 pm »

graham,

If you don't mind, I would appreciate it if you did a similar test to mine. On the IPOD, strip an album of it's tags completely, then have MC tag them including album art and tell me if it seems slow at all to you (or better yet, write times would be helpful).

Thanks for your help.

xen-uno · « **Reply #33 on:** February 26, 2003, 02:24:45 pm »

elph...

Did you install XP SP1 yet? I know it doesn't make sense since your getting great numbers from the FW drive BUT...I know one of the bug fixes was USB related...and that may apply to the FW interface as well.

10^-27

KingSparta · « **Reply #34 on:** February 26, 2003, 02:46:42 pm »

>> I know one of the bug fixes was USB related
It was but i don't think it was related

i think it had more to do with devices not seen and USB2

graham131 · « **Reply #35 on:** February 26, 2003, 02:56:23 pm »

Quote

graham,

If you don't mind, I would appreciate it if you did a similar test to mine. On the IPOD, strip an album of it's tags completely, then have MC tag them including album art and tell me if it seems slow at all to you (or better yet, write times would be helpful).

Thanks for your help.

Sorry to be a pain Auto but I just want to be clear. When you say have MC tag them including Album Art what exactly do you mean? I want to ensure that I am following the same procedure as you.

Thanks

Graham

Autoelph · « **Reply #36 on:** February 26, 2003, 05:52:08 pm »

graham, no problem:

What I do is include the album art inside the file, so in the properties in the image section, mark the box "store images inside file (if possible)". Then write the tags. The image adding part is what I'm most interested in, as this is where the largest bottleneck is occuring in MC.

Thanks again.

Xen, no, haven't loaded SP1, I'd rather avoid it if possible. I tried it on another system once and it did a number on my Outlook among other things.

xen-uno · « **Reply #37 on:** March 26, 2003, 10:34:38 am »

OK...

Just picked up a Adaptec ATA RAID controller (1200A) and set up a mirrored volume (RAID level 1). Drives are the 60 GB ATA/100 WD's as mentioned in earlier posts. Here's my results (using Sandra)....

S: (ATA-100 before RAID) and S': (mirrored RAID ATA-100 volume)
Buff Read = S: 26 MB/s, S': 77 MB/s
Seq Read = S: 25 MB/s, S': 43 MB/s
Rand Read = S: 7 MB/s, S': 8 MB/s
Buff Write = S: 18 MB/s, S': 35 MB/s
Seq Write = S: 17 MB/s, S': 32 MB/s
Rand Write = S: 11 MB/s, S': 12 MB/s
Ave Access Time = S: 7 ms, S': 6 ms

Wow!...I say again...Wow!

I had trouble installing the card initially on my Dell under W2k. Found a FlashBIOS update for the system and it installed perfectly afterwards. I think I'll sleep better at nights now.

10^-27

KingSparta · « **Reply #38 on:** March 26, 2003, 10:58:22 am »

I take it, it's faster now?

xen-uno · « **Reply #39 on:** March 26, 2003, 11:05:13 am »

According to my girl Sandra it is (the S' are new numbers). As far as a seat of the pants feeling, haven't noticed yet (it's only been in operation as a RAID for about an hour now...plus the volume was meant for relatively static music and image files). Main benefit: much more secure storage for only $60 from Amazon. Well worth it.

10^-27

INTERACT FORUM

Author Topic: MC9 and 1394 (Read 6893 times)

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph

Autoelph