Weird Encoding Stuff

[MrBlod]

I've been using B117 since the release and overall it's extremely stable. Nice job!

A couple things I"ve found (and I'm not totally sure they're *bugs*, but anyway): If I'm encoding a CD and playing a separate MP3, the play counter ticks through the seconds extremely fast...

Also, while encoding, sometimes the encoder will just stop encoding with a handful of songs in the encoding queue left over.

Sorry if these have already been submitted!

[Todd The Kiwi]

If I'm encoding a CD and playing a separate MP3, the play counter ticks through the seconds extremely fast...

Also, while encoding, sometimes the encoder will just stop encoding with a handful of songs in the encoding queue left over.


i get this even when I'm not playing music while ripping
[it's generally not a good idea to do ANYTHING while ripping or burning i thought.]
i don't think it's a bug aye

how are you selecting the tracks to be encoded/ripped?
convert all to/convert selected to/drag n drop/encoder window ?

[Tropics]

i get this even when I'm not playing music while ripping
[it's generally not a good idea to do ANYTHING while ripping or burning i thought.]
i don't think it's a bug aye

i thought the "don't touch the pc while burning" times where over after the invention of buffer underrun tech ...

[MrBlod]

Thanks for the reply.

Here's what I do:

1. Select the Rip & Encode button so that the Rip & Encode queue is up
2. Place the CD I want to rip into the drive.
3. QMP automatically adds the list of songs from the disc and Gracenote pulls the track names.
4. I click the "Encoding Start" button

QMP goes through the first few tracks and then stops. It never stops in the middle of a track, it finishes a track and then stops before finishing the whole disc.

If it helps, it *seems* like it happens more often when QMP doesn't have focus. I could be imagining that though.

[Willow of Oz]

i thought the "don't touch the pc while burning" times where over after the invention of buffer underrun tech ...

I had an old 2x non-scsci, non-buffer-overrun protecting, non-dmaing writer back in the day. You move the mouse, you get a bad burn. If you were lucky, the pointer position would actually update too.
Then, on the same machine, got a 20x all-singing, all-dancing, dma-to-the-max burner, and for kicks I'd play quake while burning, or burn off a mate's PC over just a 10mbit connection, all apples.

On the other hand, there is a gap when it has to turn off the laser, and then back on to write again. That gap I believe was getting larger as write speeds went up - Ricoh made some claims when they marketed their just-link tech against burn-proofing. On the other hand, who cares about theoretically gaps in data that readers can get past okay?

[Todd The Kiwi]

i don't do it on principle :biggrin:

anyway, Mr Blod has issues -

you're talking audio cds and mp3 files right?
and you're using qmp β117 too.
what mp3 encoder are you using? lame?
what do the files that DO get encoded sound like ?
have you tried encoding to say OGG or WAV what happens then?
you have a P.O.S computer or half decent or what?

[MrBlod]

Yes, I'm using B117 to rip audio CDs to MP3s via the Lame encoder (3.97). The MP3s that *do* get encoded sound find -- it's almost like QMP just gets lazy and stops before the tracks in the queue are finished. I haven't tried ripping to WAV or OGG lately, but I'll try that later.

As far as computer specs go, I have an older computer but not one I'd call a P.O.S., at least not yet:

P4 2.66 GHz; 1 GB RAM; XP SP2

Any ideas?