Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Extreme transcoding slowdown (Read 2163 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Extreme transcoding slowdown

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?

Extreme transcoding slowdown

Reply #1
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.

Extreme transcoding slowdown

Reply #2
It might be a better idea to do all the converting on the harddrive and then copy the files to the flash drive.

Extreme transcoding slowdown

Reply #3
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.
Microsoft Windows: We can't script here, this is bat country.

Extreme transcoding slowdown

Reply #4
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

Extreme transcoding slowdown

Reply #5
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.