IPB

Welcome Guest ( Log In | Register )

> foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.
Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.


See also: Hydrogenaudio Terms of Service.

 
Reply to this topicStart new topic
Extreme transcoding slowdown, When output directory is a flash drive
slks
post Sep 21 2012, 01:06
Post #1





Group: Members
Posts: 375
Joined: 31-March 06
From: Houston, Texas
Member No.: 29046



Today I decided to load up a flash drive with some MP3s. Some of the source files were already MP3, some of them were FLAC. So I loaded them all up into a foobar playlist and sorted by file type.

I used the copy/move option in the drop-down menu to copy over the MP3s verbatim, and that operation took a reasonable amount of time.

Then, I started transcoding the FLACs to MP3 (LAME 3.98). At first, the conversion speed was hovering around 90-100x, which is normal for my computer. But then the speed readings dropped to 0x. I've seen it do this briefly during conversions before - for a few seconds - which I supposed was due to the encoder waiting for the next file to be read off the disk.

But this time, the encoding speed stayed at 0x for long stretches of time - whole minutes, or more. Then would come a brief 5-10 second spurt of 80-100x encoding, then another minute or so of 0x. A conversion that should have taken 10 minutes took more like 45.

I don't think my flash drive is slow enough to be the cause of this. The simple move operation didn't take particularly long. It was only when I tried encoding the files, outputting to the flash drive, that I got this enormous slowdown.

Could this be some kind of bug with foobar, or maybe even LAME?


--------------------
http://www.last.fm/user/sls/
Go to the top of the page
+Quote Post
washu
post Sep 21 2012, 03:23
Post #2





Group: Members
Posts: 134
Joined: 16-February 03
From: Ottawa
Member No.: 5032



Flash drives by default in Windows are set to have no write cache on them. This is so when you yank them out the data on them is always consistent. This isn't a big deal when copying reasonably large files sequentially, such as the MP3s. However, if you try to copy many small files or try to perform many simultaneous I/O operations the drive simply cannot keep up. Assuming you have more than one core in your PC Foobar will be doing the latter.

You can try the following:

- Set Foobar to only use one thread when converting.

- Change the write policy on your flash drive for performance. You can do this in the properties of the drive in device manager. If you do this then you should always use the Safely Remove Hardware option to dismount the drive before removing it.
Go to the top of the page
+Quote Post
nastea
post Sep 21 2012, 04:32
Post #3





Group: Members
Posts: 38
Joined: 30-July 12
Member No.: 101867



It might be a better idea to do all the converting on the harddrive and then copy the files to the flash drive.
Go to the top of the page
+Quote Post
Peter
post Sep 21 2012, 06:57
Post #4





Group: Admin
Posts: 3269
Joined: 30-September 01
Member No.: 84



Known problem.
Writing the new file is up to the encoder; if it writes in lots of small chunks, external flash drivers perform extremely slowly. If the issue is isolated to specific encoders only, perhaps you should report it to encoder authors.


--------------------
This job would be great if it wasn't for the users.
Go to the top of the page
+Quote Post
slks
post Oct 3 2012, 08:55
Post #5





Group: Members
Posts: 375
Joined: 31-March 06
From: Houston, Texas
Member No.: 29046



Hmm. And here I thought flash memory was supposed to be better at small, randomly placed writes. But if there's no write caching, I suppose that could explain some of the difference. I'll enable it and see if that helps - I'm the only one who uses this computer, and I'm not one to go yanking out USB devices randomly, as tempting as it is.

In the next few days I'll do testing on these things: Write caching, different flash drives, different encoders - to see what contributes.

System specs for anyone curious:

CPU: AMD Phenom X4 9850 (original Phenom, quad core)
Memory: 4 GB, DDR2-800
Motherboard: Asus M2N-SLI Deluxe
Chipset: nForce 570 SLI
Flash storage: Sandisk U3 Cruzer (various sizes)
OS: Windows 7 64-bit


--------------------
http://www.last.fm/user/sls/
Go to the top of the page
+Quote Post
washu
post Oct 3 2012, 14:56
Post #6





Group: Members
Posts: 134
Joined: 16-February 03
From: Ottawa
Member No.: 5032



QUOTE (slks @ Oct 3 2012, 03:55) *
Hmm. And here I thought flash memory was supposed to be better at small, randomly placed writes.


RAW flash memory is actually pretty bad at random writes due to the large block size (up to 512K). That means that when the OS writes a block (4K) the whole 512K block has to be read, updated and then written out again. In a good SSD the controller works around this problem. However, in all but the most expensive USB drives the controller is as simple and cheap as possible, so random writes are slow.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd April 2014 - 10:42