ARCHIV

Ahoj,
jako vypalovací program používám K3B v Mandrivě 2007.
Chci se zeptat - jak vypálit složku s .mp3 soubory? Když přidám složku do projektu, a dám vypálit, objeví se okýnko, ať vložím (nebo vyberu) soubory. Díky

obvykle : spustit k3b, new data cd(nebo dvd) project, pretahni soubory , vypalit

Děkuju.
kdyby to bylo takhle jednoduchý, tak tu nejsem.
Normální soubory jdou, ale složky za živýho boha ne...

Zkontrolujte si prava u slozky a souboru, ktere vkladate do projektu. K3b umi slozku vlozit jak do datoveho tak do audio cd. Pokud jsou prava v poradku a nechybi vam nejake pomocne programy (Nastaveni - Nastavit k3b - Programy), bude chyba nejspis v Mandrive.

Zdravim FB

Je to divný..ani samotnej soubor ve složce nejdou...
Soubory vznikly tak, že sem otevřel AudioCD, a složku MP3 (kterou vytvořil Linux) jsem jednoduše zkopíroval...a velikost je 0kb...já to nechápu. :/

zkuste se prihlasit jako root a vypalit to.. jestlize to pujde tak je problem s pravama.. hledejte prikaz chmod (man chmod) jestli ne , je chyba nekde jinde.. mozna by to pak chtelo vice info, dukladneji to popsat

Zdravím
Jestli dobře chápu, pak jste se pokoušel kopírovat do složky soubory z CD, které vzniklo z analogového signálu ( tedy tam nejsou soubory mp3 - např. trackX.mp3 ale buď jen trackX nebo trackX.ccd ). Audio CD totiž za normálních okolností nejde jen zkopírovat. Musíte narypovat, ( což je specialní případ kopírování ) a poté převést do MP3 formátu.
Zkuste si buď man lame ( http://lame.sourceforge.net/ ), nebo upřednostňujete - li GUI, pak já v KDE používám KAudioCreator (http://www.icefox.net/programs/?program=KAudioCreator). Jen nevím jak jste takové AudioCD pod Linuxem otevřel - mě ho Linux nepřipojí.

nejjednodušší naripování lze udělat příkazem
cddparanoia -B (příp. doplnit ...-d /dev/hdc ..)

Je to jasne, poukousite se vypalit soubory s nulovou delkou. Pravdepodobne jste je vytvarel v konqueroru a chybi vam knihovna, ktera prevod do mp3 umoznuje. Nevim ted z hlavy ktera to je, ale hledejte vse co obsahuje slovo "lame". Nejspis to bude program "lame" samotny. Ted jsem to nedavno resil v Mandrive taky. Pokud neuspejete, tak pouzijte na ripovani cd treba program "grip" a urcite pak soubory vypalite.

S pozdravem FB

Díky za rady hoši...
Už jsem si stáhl ten LAME, ale když dám instalovat, zobrazí se mi okýnko, a v něm:
Některé požadované balíčky není možné nainstalovat: lame-20011211-1.src (z důvodu nesplněného gcc3)
Co radíte? Díky :)

Vtip je v tom, ze balíček lame a mnoho dalších je připraveno pro vaši verzi Mandrivy a vy pak pohodlně příkazem "urpmi lame" nainstalujete balíček bez řešení závislostí.

Dost dobře nechápu co momentálně řešíte. Pravděpodobně máte starší překladač programovacího jazyka C/C++ než vyžadují závislosti balíčku který se pokoušíte nainstalovat. Pak existuje několik možností jak to řešit.

1) Nainstalovat / Upgradovat gcc z vašich repozitářů.

2) Stáhnout zdrojáky projektu LAME, v archívu ( s příponami tar, tgz, tar.bz, ... ) rozbalit je do /usr/local/src a obvyklým postupem zkompilovat a nainstalovat. Tam by verze překladače (aspoň ve většině případů) neměla být až tak velkým problémem. Konec konců, já sám upřednostňuji instalace software přímo ze zdrojáků.

Zde v diskuzich lze myslim najit vice nez dostatek duvodu, proc neinstalovat veci prostou kompilaci ze zdrojaku, at jiz varovani s vysvetlenim proc to nedelat, tak odstrasujicich pripadu dusledku.

Navic bych veril tomu, ze lame je jeden z typickych programu, ktery neni dobry kompilovat prvnim kompilatorem, ktery vemete do ruky, protoze prave takoveto programy maji tendenci narazet na nejruznejsi obskurni chyby v gcc.

Nicmene prvotni problem spociva v tom, ze prvotni tazatel si stahnul zdrojovy balicek (jak je koneckoncu videt z nazvu) misto toho aby stahnul jiz zkompilovany (takove maji v nazvu mimo jine nazev architektury, pro kterou jsou urceny, rozhodne ne src).

Zda instalovat, nebo neinstalovat soft ze zdrojových kodů je věc pouze názoru (uznávám - jediný závažný problém, na který jsem narazil byla kompletní deinstalace takového software) Já v něm vidím zase převahu pozitiv a vsadím se že i ta byla na různých místech popsána. Za tímhle si stojím.

"Některé požadované balíčky není možné nainstalovat: lame-20011211-1.src (z důvodu nesplněného gcc3)"
Nevím jak Vám, ale mě to připadá spíš jako typické hlášení balíčkovacího programu (asi něco na bázi rpm) než chybová hláška kompilátoru projektu. Takže - jedná se o závislost v balíčkovacím programu, kterou tam dodal autor balíčku (což vůbec nemusí znamenat, že to požaduje samotný projekt). Přípona v hlášení je irelevantní.

Samotný překlad projektu není až tak závislí na verzi gcc. Rozhodně ne LAME - sám ji instaluji ze zdrojáků. Bez problémů. Do balíčků a některých projektů je vkládána zavislost na určitou verzi kompilátoru kvůli knihovnám libgcc, které mají dost specifické použití.

Nicméně neříkám, že váš předešlí navrch s urpmi je špatný. Pouze jsem doplnil další možnosti řešení. Je na tazateli co si vybere... :-)

Je pomerne rozumne, ze zdrojove balicky maji zavislost na nejakem kompilatoru - co byste s nimi chtel bez nej jako delat? A pro zacinajiciho uzivatele je myslim daleko vhodnejsi, kdyz mu to pri pokusu o rozbaleni zdrojoveho balicku vypise, ze nema kompilator a tudiz dela cosi nepravdepodobneho, nez kdyz rozbali tarball a pak spusti configure, ktere vypise jakesi krypticke chybive hlasenin s naprosto stejnym vyznamem.

Nicmene tvrzeni, ze zdrojovy balicek je neco uplne jineho, nez puvodni tazatel chce je spravne a myslim, ze neumite vyrobit argument, ktery to popira. Uz jenom proto, ze vetsina uzivatelu ma jakousi (do jiste miry mylnou) predstavu o tom, jak se kompiluje program z tarballu a ve vetsine pripadu nemaji nejmensi tuseni, ze existuje neco jako zdrojovy balicek.

Preklad programu je zavisly na kompilatoru hned ve dvou ohledech, jednak je potreba nejaky kompilator a druhak je potreba kompilator, ktery generuje spravny vystup, coz se o gcc v nekterych pripadech rici neda (ackoli je to dnes vyrazne lepsi nez v dobach, kdy jeden nejmenovany distributor distribuoval verzi gcc, ktera byla rozbita opravdu hodne). A nejruznejsi kodeky jsou prave ta kategorie programu na kterych jsou chyby v kompilatoru videt opravdu hodne.

libgcc je knihovna obsahujici podpurne rutiny pro runtime gcc, ktere neni potreba mit primo v runtime a mohou se tedy sdilet mezi vice bezicimi procesy, nicmene volani rutiny ze sdilene knihovny je v mnoha ohledech pomala operace a tudiz je snaha, libgcc nepouzivat, pokud to neni nutne (a na i386 programy v C libgcc na nic nepotrebuji, jelikoz to slozite umi procesor primo a to jednoduche je levnejsi inlinovat primo do kodu programu nez kvuli tomu volat do sdilene knihovny). A kdyby jste pouzival balickovaci system, tak na problemy s kompatibilitou libgcc vubec nenarazite a rekl bych, ze ohledne kompatibility jsou daleko zajimavejsi jine casti gcc runtime, napriklad libstdc++.

A muj nazor, ze programy si primo z tarballu kompiluji a do systemu instaluji pouze ti lide, kteri neumi/jsou lini si svoji upravenou verzi ubalit jako balicek mi nevyvratite. Ma pochopitelne smysl ty tarbally primo kompilovat, ale pouze pro jakesi testovani spojene s instalaci nekam uplne jinam nez do vychoziho umisteni globalniho pro cely system (a muj nazor je, ze clovek, ktery ma duvod toto delat vi pomerne dobre, proc to chce delat).

Moment. Asi si nerozumíme nebo ujíždíme z tématu.

Nikde netvrdím co uživatel chce nebo nechce a ani to nevyvracím. Stejně tak Vám nevyvracím Vaše názory. To rozhodně ne. Jen tvrdím, že existují i jiné pohledy na věc a tudíž i jiná řešení a názory. Otázka které z nich lépe řeší danou situaci nebo problém je čistě na uživateli. Co se týče Instalaci softu tam je to vidět nejlépe. I ty slavné balíčkovací systémi maji své problémi a nevýhody. A nějaké řešení které by uspokojilo potřeby všech a ošetřilo všechny situace je zatím v nedohlednu.

Co se týč závislostí: Mám následující skušenost: Program který byl instalován jako balíček, nainstalovat nešlo bez splnění požadovaných závislostí, ale jeho instalace ze zdrojových kodů prošla uspěšně. Proč asi? (abych byl uplně přesný narazil jsem i na opačný případ, ale ten byl opravdu jediný).

GCC je navrhován tak aby stejný zdrojový kod byl schopen vždy přeložit tak aby výsledný program dával vždy stejné výsledky. Mám na mysli, že např. :
int i = 1;
i++;
i bude v tomto případě obsahovat vždy 2 a né 1, 3 nebo cokoliv dalšího a o to v tuhle chvíli jde. Jsou to opravdu specifické věci, které mohou být změněny verzí překladače. To jak tento kod překladač implementuje v binární formě, je jiná věc - sice související, ale do jiné diskuze.

Protože vím co je libgcc (nebo i libstdc++) a s ohledem na výše uvedené, tvrdím že je nesmyslem uvazovat uzivatele na jednu danou verzi prekladace. Mimochodem ten kdo používá zdrojový kód snad ví že potřebuje překladač.

Mám verzi LAME 3.97 a dal jsem si tu práci a našel jsem specifikace překladače: 2.96 výše

uvědomte si prosím, že na začátku tohoto vlákna byl dotaz začátečníka, který vytváří mp3 soubory přetažením myši z okna konqueroru na plochu při absenci programu "lame" v jeho systému. Po té, co omylem někde našel zdrojový kód ke staré verzi "lame" v rpm balíčku, se mu tento kvůli závislostem nepovedlo nainstalovat (naštěstí). Vaše, byť dobře míněná rada, aktualizovat gcc, mu bude platná jako mrtvému zimník.

A budete-li si dále psát s Alešem Haklem (ideálně v jiném vláknu) kolik je i++ prosím dejte pozor. Ve slovech systémi a problémi se na konci píše tvrdé "y". A ve slově skušenost se na začátku píše "z".

S pozdravem František Bublík

Ano, já jsem se nechtěl dohadovat o tom kolik je i++, ani o ničem dalším. Toho, že při psaní dělám chyby jsem si vědom a omlouvám se za to, nicméně jsme lidé a ti obecně dělají chyby, proto prosím o shovívavost.

Taky mě napadlo, že dotyčný je pravděpodobně začátečník, ale moje dobře míněné rady byli z mé vlastní zkušenosti. Kdysi jsem taky začínal.Jen jsem vyděl jistá východiska, která (alespoň podle mě) tak jsem je prostě napsal. Nějak podobně kdysi pomáhali jiní i mě v začátcích.

Tak to je hezke :) gcc 2.96 je prave ta vyse zminena totalne rozbita verze a podivejte se do configure.in jaky uzasny specialni pripad tam kvuli tomu je.

Coz krasne ukazuje, ze cilem kompilatoru je generovat spravny kod (nikoli nutne vzdy stejny), ovsem kompilator je software jako kazdy jiny a tudiz je nepravdepodobne, ze bude za vsech okolnosti fungovat spravne. A to jak ten konecny vystup vypada je v tomto ohledu ta zajimavejsi cast, jelikoz konverze z nejakeho programovaciho jazyka do RTL ci neceho podobneho je pomerne jednoduchy a snadno pochopitelny krok, ovsem jak program v nejakem abstraktnim modelu napasovat na konkretni procesor s omezenym poctem registru je otazka jina a jak to udelat tak, aby vysledny program byl co nejrychlejsi je uz teprve uplne jiny problem. Mimochodem v C existuje velka mnozina korektnich programu, ktere muzou po kazde kompilaci delat neco uplne jineho, ale to sem opravdu nepatri.

To ze ze zdrojovych kodu nainstalujete neco, co z balicku kvuli nesplnenym zavislostem nenainstalujete je jednoduse tim, ze nakonec dostanete program s jinou funkcnosti. Valna vetsina programu si pred kompilaci detekuje veci na kterych zavisi a v pripade ze nenajde nejakou knihovnu, ktera neni potreba k hlavnimu ucelu programu, ale pouze pro nejakou snadno vypustitelnou funkcnost, tak takovou funkcnost vypusti a knihovnu jiz nepotrebuje. Druha moznost je opacna, ale principialne ekvivalentni: funkcnost potrebujici danou knihovnu je ve vychozim nastaveni daneho programu vypnuta a clovek co tvoril balicek ji sam explicitne zapnul, opet o ni tedy prijdete.

No mě to moc nepřesvědčilo. Ale už o tom taky uvažuji delší dobu :
Co kdybychom si založily vlastní vlákno a tam si o tom pěkně popovídali. O programování jsem si už dlouho nepokecal :)

Jen poslední moje reakce k tomuto : ta verze gcc tam nebyla uvedena jako ta hlavní a samozřejmě do configure.in jsem se díval. Šlo mi spíš o to vyjádřit nějakou myšlenku. Ale to už opravdu jindy.