bheller.com

NEXUS6 a écrit :je n'interviens jamais dans ce topic ...
sauf ce soir

la prochaine version du rippack (s'il y en a une) ne devrait-elle pas être développée en .net ?

Non car cela aurrai aucun intéret...

pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...

pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple)

Oui mais est ce vraiment utile et en quoi ??? ( en d'autre terme, c'est pas parcqu'il y a un effet de mode, utile pour certaines choses que tout doit être fait comme cela ) )...

Dc-F

NEXUS6 a écrit :pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...

Honettement je ne vois pas trop l'intéret... Tous les softs qui ont tenté l'expérience du .net ont fait marche arrière pour le moment... Overnet (edonkey) était sorti en .net au début puis est revenu en version "normale".

Le fait de télécharger le framework très lourd est beaucoup trop limitatif pour un apport minime...

bruce a écrit :

NEXUS6 a écrit :pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...

Honettement je ne vois pas trop l'intéret... Tous les softs qui ont tenté l'expérience du .net ont fait marche arrière pour le moment... Overnet (edonkey) était sorti en .net au début puis est revenu en version "normale".

Le fait de télécharger le framework très lourd est beaucoup trop limitatif pour un apport minime...

En fait je vais utiliser ce post pour étaler ma science. lol.
Petite correction de puriste on dit pas développer en .NET mais développer pour .NET (je dit ca sans critiquer personne). Parce que .NET est la plateforme qui fait tourner les softs programmés spécialement pour elle. Pour les newbies .NET est une technologie similaire a JAVA développé par Microsoft (sans doute à la suite des maintes et maintes procès qu'il ont eu avec SUN Microsystems.) même si .NET est similaire, il y a de grandes différences avec Java. Par exemple .NET est entièrement dans le domaine public (autrement dit pas de droit a payer pour développer une plateforme sur un autre système d'exploitation ou bien pour développer pour cette plateforme. D'ailleurs il existe déjà des plateforme pour Mac et Linux si je ne m'abuse). Les programmes développés pour .NET peuvent tourner sur n'importe quelle plateforme .NET donc un programme fait sur Windows tournera sous Mac OS et sous Linux.

Seul pbm : la technologie est encore très jeune et bien des librairies ne sont pas encore implémentées ce qui devrait changer avec longhorn puisqu'aux dernières nouvelles le bureau windows et un tas de composants sous Longhorn devraient être programmés pour .NET. Mais d'ici a 2005 (date de sortie officielle de Longhorn) il y a de l'eau qui va passer sous les ponts comme qui dirait.

Donc je serais de l'avis de Bruce sur ce coup la, développer pour .NET est encore prématuré même si la prog pourrait tenir compte d'une évolution future vers cette plateforme.

merci de l'info

Clair et net (sans jeu de mots), merci Wazabbe

wazabbe a écrit :

bruce a écrit :

NEXUS6 a écrit :pourtant, il me semble que bcp de choses s'orientent vers le .net (Delphi 8 par exemple) ...

Honettement je ne vois pas trop l'intéret... Tous les softs qui ont tenté l'expérience du .net ont fait marche arrière pour le moment... Overnet (edonkey) était sorti en .net au début puis est revenu en version "normale".

Le fait de télécharger le framework très lourd est beaucoup trop limitatif pour un apport minime...

En fait je vais utiliser ce post pour étaler ma science. lol.
Petite correction de puriste on dit pas développer en .NET mais développer pour .NET (je dit ca sans critiquer personne). Parce que .NET est la plateforme qui fait tourner les softs programmés spécialement pour elle. Pour les newbies .NET est une technologie similaire a JAVA développé par Microsoft (sans doute à la suite des maintes et maintes procès qu'il ont eu avec SUN Microsystems.) même si .NET est similaire, il y a de grandes différences avec Java. Par exemple .NET est entièrement dans le domaine public (autrement dit pas de droit a payer pour développer une plateforme sur un autre système d'exploitation ou bien pour développer pour cette plateforme. D'ailleurs il existe déjà des plateforme pour Mac et Linux si je ne m'abuse). Les programmes développés pour .NET peuvent tourner sur n'importe quelle plateforme .NET donc un programme fait sur Windows tournera sous Mac OS et sous Linux.

Seul pbm : la technologie est encore très jeune et bien des librairies ne sont pas encore implémentées ce qui devrait changer avec longhorn puisqu'aux dernières nouvelles le bureau windows et un tas de composants sous Longhorn devraient être programmés pour .NET. Mais d'ici a 2005 (date de sortie officielle de Longhorn) il y a de l'eau qui va passer sous les ponts comme qui dirait.

Donc je serais de l'avis de Bruce sur ce coup la, développer pour .NET est encore prématuré même si la prog pourrait tenir compte d'une évolution future vers cette plateforme.

Bha c'est surtout que le framework n'est pas installé par défaut dans un seul windows disponible sur le marché (donc imaginez les "anciennes" versions) et que tous le monde n'a pas une connexion haut débit pour chopper ce framework.

De plus l'encodage DivX (ou consort) fait appel à des codecs et autres éléments intégrés au système windows. Oui le logiciel ".net" tournera ailleur (mac, linux, bsd...) mais ne pourra rien faire tel quel vu qu'il fodrai repenser tous les appels vers les éléments d'encodage...
Il n'y a pas AviSynth sur Linux, pas de Vdub non plus... Oui il y a des alternatives mais dans ce cas autant programmer un soft complet pour Linux ou Mac plutot que chercher à adapter un soft windows à coup de patch et modules...

Bon, pour mettre mon grain de sel...
Je vois que les petits jeunes en première année de fac apprennent à développer en java. Et quand ils font un stage en entreprise ou quand ils cherchent du boulot, ils sont immédiatement opérationnels en Java sur les grands systèmes (AIX, Sun-OS, etc) en même temps que chez eux sur Windows ME ou sur Linux.
Si on les verrouillait sur .net, ils apprendraient un truc beaucoup plus limité, et devraient réapprendre java...
Bon, désolé, on s'écarte du sujet principal qui est le Rippack.

bruce a écrit :................................................................................................merde. Là c impossible de faire pareil pour la vidéo, vus que le débit change déjà d'un film à l'autre...
...................................................

bonjour,
je n'utilise pas bcp rippack en ce moment, mais on me demande souvent de traiter des sequences video (assez enormes de qqs 800mo a plus de 1000mo). J'utilise majoritairement vdub pour le reencodage video et audio. Je me dois donc de calculer au plus juste pour le bon bitrate (2pass) en tenant compte du debit audio en mp3 (souvent 56kbps 24khz stereo). Je realise tout simplement un calcul : ((Taille en ko divise par dureefilm en seconde)multiplie par 8) moins debit final du mp3 en kbps. La taille finale rentre toujours sur un cd (ds ce cas de 700mo) avec une qualite optimisee (divx 5.1.1 pro, profils desactives). Mon calcul ne tient pas compte du taux compression divx. Je ne touche pas aux reglages specifiques a nan/vdub sbc/brc ni aux settings image ds codec.
Tu pourrais utiliser ce type de calcul pour le bitrate video mais il ne prend pas non plus en compte la nature photo du film: dynamique (bcp mouvt) ou palette etendue (tres coloree), ces deux variables ayant pour effet d'influer bcp sur rapport taille/qualite du film. Ex: Mission Impossible 2 a moins de 700mo affiche des images pixellisees sur les frames d'explosion et de mouvements rapides.
Autre commentaire a propos du bitrate mp3: ds la version 16beta, il n'est pas possible d'utiliser un vbr 56kbps 24kbps stereo, le menu de choix se basant sur une onde wave de 44100hz et non pas de 48000hz ce qu'on obtiendrait naturellement avec ac3dec. Si je choisis un tel vbr, je me vois oblige de modifier l'echantillonage de l'onde (de 44.1khz a 48khz) avec le risque non negligeable de devoir qqfois reajuster la tempo sonore sous peine d'obtenir un decalage video/audio apres multiplexage.
Je sais que ton progr partait au debut pour simplifier le divixage (notamment pour les neophytes), mais je serais vraiment agreablement touche si tu pouvais integrer ce genre de manip ds une section pro de la nouvelle version (bien avant les nouv. opt que tu as proposes).
Je te salue, et je vais me coucher....
Les infos du forum sont tres interessantes. Tous sujets confondus, je lirai la suite demain soir, euh matin...

J.

@ Bruce: Est-ce que tu pourrais nous dire ou tu en est dans la programmation du nouveau Rippack ?
Merci

pas commencé....

et le site

theseeker a écrit :Autre commentaire a propos du bitrate mp3: ds la version 16beta, il n'est pas possible d'utiliser un vbr 56kbps 24kbps stereo, le menu de choix se basant sur une onde wave de 44100hz et non pas de 48000hz ce qu'on obtiendrait naturellement avec ac3dec. Si je choisis un tel vbr, je me vois oblige de modifier l'echantillonage de l'onde (de 44.1khz a 48khz) avec le risque non negligeable de devoir qqfois reajuster la tempo sonore sous peine d'obtenir un decalage video/audio apres multiplexage.

Le son d'origine des DVD est en 48 Khz... Ensuite le rippack ne propose pas de VBR en MP3.

Schummy a écrit :et le site

Je suis dessus quand j'ai le temps de m'y mettre... On va y arriver

Faudrait peut-être penser à mettre au courant les gens de l'avancement du projet ?

C'est un avis très intéressant et plein de nuances, qui montre à tout le monde la puissance de ta réflexion. Merci d'encore nous éclairer à l'avenir de tes pensées transcendentales.

bah c'est peut être un geste d'exaspération...
le temps passant n'est pas fait pour arranger les choses quand on crois encore au projet rippackXP

Bien sûr, je peux comprendre qu'on ait espéré et qu'on soit déçu, mais il y a la façon de le dire. Et je maintiens qu'étant donné que Bruce a fait son soft gratuitement, il ne doit rien à personne...