El enlace que te dejé habla de problemas con los IRQ, lo probaste?

Sí, pero esa opción sólo es en la captura y no para un video ya capturado como creo que se refiere langostino  

Muy escuetamente, no  

..... y ya que has empezado con el divX Author, no te costará hacer lo mismo con su genérico TMPGEnc DVD Author 3 with DivX® Authoring (ver. 3.1.2.176)

CitarEntonces, cuando recortes siempre hay que desmarcar mantener relación de aspecto en modificadores?

No, es erróneo. Si la desmarcas se deforma la imágen. Es esto preocupante?, no siempre, el error cometido puede ser mínimo e insignificante, pero existe.

CitarO sea, que ahora el preview lo visuliza correctamente y se me verá bien cuando lo guarde

También incorrecto. El preview sólo es eso un preview. Previsualiza los resultados si al renderizar utilizas la misma configuración en el códec que la que tiene el proyecto de vegas.

Dependiendodel códec utilizado te deja variar más o menos parámetros.

No consigo reproducir tu error. Sólo se me ocurre que el bitrate que utilizas al comprimir el video hace que el video producido no exceda de los 10 MB, con lo que no influye y a tí te parece que sí.

Es normal, pero desconozco si existe una variable que cambie este comportamiento (por si interesara).

Configura las propiedades del proyecto de vegas tal y como quieres que resulten, si 16/9 pues 16/9, si 4/3 pues en 4/3. En el preview de vegas, verás cómo quedará con esa configuración al renderizar usando la misma configuración en el códec elegido (Cuidado!, no influye en el renderizado, pero te muestra cómo quedará).

Ahora juega con el pan/crop de vegas (como indica weapons), para eliminar las bandas negras (no las eliminarás, sólo indicarás que no las tenga en cuenta en la renderización si las tiene, sólo renderizará el interior del cuadro marcado en el crop).
Ahora debes jugar con track motion, ampliando o disminuyendo para que ocupen toda la ventana del preview en vegas y que desaparezcan las bandas negras.

Renderiza con ffdshow e indica en el apartado de "salida", en la personalización del códec, "proporción de imagen" como hayas decidido anteriormente, 4:3 o 16:9.

Este es gratuito, su autor Mike Crash http://www.mikecrash.com/modules.php?na ... oad&cid=13

El siguiente paso sería comprobar otra cámara y asegurarte que el puerto del portátil no esté dañado.

Mis última ideas:
- Cliv dcho ratón sobre el conflicto en el administrador de dispositivos de windows y "actualizar controlador", mira si dispones de un cd del propio portátil y oblígale a buscar en él el controlador.

- http://facs.iespana.es/irq_wxp.htm

No te queda otro remedio que testear la cámara en otro ordenador, quizá un amigo, familiar, vecino, .....,

Desconecta la cámara.
Elimina los dispositivos que te aparecen con el triangulito.
Re-inicia el portátil.
Asegúrate que ya no hay avisos en los dispositivos.
Conecta la cámara al portátil
Puedes transferir ahora?.

En otro orden de cosas:
- La cámara no venía con un CD con soft/drivers?.
- Mira el manual de la cámara, en el apartado de captura/transferencia por puerto i-link, firewire, que no debas poner la cámara en un modo específico.

Otras:
- Conecta la cámara a otro ordenador. (importante para descartar problemas en la propia cámara o en el puerto del portátil)
- Cable en mal estado.

Si puedes mezclarlos, pero uniformando a una u otra velocidad, decide a 24 fps o 29 fps y unifica el que debas. Después edita y renderiza manteniendo el número de frames por segundo.

Yo tampoco soy capaz de reproducir tu error.

Renderizo sin problemas sólo audio en ac3 pro y es capaz de generar el .iso para blue ray sin problemas. (Genero el iso puesto que no dispongo de blue ray)

En cuanto a la primera pregunta, no ganas nada pasando el video editado a "no comprimido", ya que tu original está en un formato para edición y no demasiado comprimido (13 GB/h).

En segundo lugar, ganarás tiempo comprimiendo desde vegas directamente a mpeg-2 (como ya ha indicado Doris). Vegas y architect utilizan el mismo motor de renderizado, Mainconcept. (el tiempo lo ahorras en una única recompresión, al cargar en architect, como está en formato, no recomprimirá sólo creará la estructura).

Yo de tí me fijaría mucho en lo que dice Gspot de tu video original en cuanto a la dominancia de campo (superior o inferior), y lo mantendría hasta el final.

En cuanto a la diferencia que mencionas al inicio del hilo entre comprimir con canopus (edius) y vegas, no debería ser demasiado visualizable y más tratándose de ediciones de 45 min. en los que el bitrate final del video en mpeg-2 puede ser de 8.000 kbps (el teórico del formato). Si te apetece cuando termines el trabajo experimenta con él y asegúrate que todas las opciones son correctas al configurar el códec en el procoder (tasa de bits, dominancia de campo, ....).

El problema quizá es más aparatoso al tener que reconvertir PAL a NTSC, aunque esto puedes experimentarlo utilizando la recompresión en DV, quizá al no cambiar el códec el paso de PAL a NTSC sea más suave.

Para otra ocasión (o después para seguir haciendo tus pruebas), captura directamente con vegas. La diferencia estará en que éste utilizará su propio códec o el de mainconcept y si trabajas con vegas pro y renderizas la edición a DV, sólo recomprimirá donde afecte lo editado, el resto mantendrá el original.