cdj-1000 sd-merger, voor betalen? (2/2)

   LOCKED 

Het bekende probleem: Je draait met 2 cdj-1000mk3's, maakt gebruik van de SD-kaartjes, en slaat dus op beide kaartjes cue-points op. Een manier om de cue-points van de kaartjes samen te voegen, zodat beide kaartjes alle nieuwe cue-points bevatten, is er echter niet.

Vraag aan jullie:
Maak je gebruik van de SD kaartjes en zou je voor een programma'tje willen betalen die de cuepoints/wavedata samen voegt?

Ik denk er namelijk over om eens te gaan zoeken naar iemand die zoiets kan programmeren, maar dat zal dan wel geld kosten. Als er veel mensen interresse hebben in zoiets dan kan er misschien een handeltje van gemaakt worden dmv een vrijwillig donatie-systeem of simpelweg het programma'tje verkopen, zodat samen de kosten gedragen kunnen worden.

Tot nu toe heb ik zelf alleen last van het probleem als ik in een discotheek met 2 mk3's heb gedraait, maar over niet al te lange tijd zal het probleem zich ook thuis voor gaan doen (als ik een 2e mk3 koop). Een dergelijk programma'tje is natuurlijk geen absolute noodzaak, maar het maakt het allemaal wel veel makkelijker. (dus niet het topic spammen omdat je manieren weet om er 'omheen' te werken).

Behalve het samenvoegen van de data van de 2 SD-kaartjes zou een manier om de gegevens van de mk3-SD-kaartjes om te zetten naar mk2-MMC-kaartjes en andersom ook handig zijn. Hiervoor geld de zelfde vraag.

Poster: Lead
Ik denk niet dat je in een editor (hot) Cue's en Loops hoeft te kunnen aanmaken, die zul je toch op de Cd willen maken ivm precizie.

 
Denk inderdaad dat je dat sneller en beter kunt doen op de CDJ zelf dan in een (brakke) editor. Maar dat is ook niet echt de taak van een merger ..  Normaliseren van waves is eigenlijk al niet echt wat erinhoort, maar vooruit..  editten (bv switchen van loops naar andere buttons, of editten van loops dmv invoeren M:S:F data) zou nog wel kunnen, maar in feite is de sky the limit

Qua mergen, ideaal zou natuurlijk een workflow in ongeveer deze volgorde :

• Check ingelezen CD ID met data in geheugen.

1. if !(exist) : toevoegen van complete CD
2. if (exist) : check track nr

• if !(exist) : toevoegen van alle punten van de track
• if (exist) : check positie Cue Punt van kaartje

1. if !(exist) : toevoegen Cue Punt aan data van track
2. if (exist) : check volgende

 
Zo ongeveer werkt het ook. As said, de structuur is bekend, dus progsel is niet echt ingewikkeld. Heb vanavond niet veel tijd gehad, dus weinig aan kunnen doen..

Hmmz.. nu loop ik toch tegen een niet al te klein probleem aan

Ik ben de checksum aan het verifieren en genereren, maar de uitleg hierover klopt volgens mij niet helemaal met wat er daadwerkelijk gedaan wordt. Normaal zou de hele datafile (exclusief de checksum) moeten worden opgeteld (16bits blokken), en de uitkomst is de (16 bit) checksum. Vrij simpel maar dit werkt alleen niet .

Wel belangrijk natuurlijk aangezien je dit wel nodig gaat hebben zodra je een aanpassing gaat doen aan de datafiles Ongetwijfeld dat ik iets niet helemaal goed doe, maar zie niet precies wat. MSB/LSB swaps, verschillende offsets, verschillende ranges meenemen inde checksum, maar niets genereerd de originele checksum...

Zal dus even een hobbel worden, tenzij iemand zin heeft om zelf het checksum gedeelte uit te vogelen


[edit]
Omdat ik wat problemen heb met de checksum, de rest eventjes een beetje op orde gebracht.

Dit zou ongeveer de include header moeten worden met alle nodige functionaliteit:

http://www.perihelion.nl/mk3merge/cdj.h


Mijn C is een beetje roestig (toch alweer teveel jaartjes geleden ), maar op zich zou het zo ongeveer wel moeten kloppen.
[/edit]

Update:

De API is af. Ik kan hem alleen niet testen omdat ik de checksum nog niet aan de praat krijg, maar zodra ik dat heb dan zijn we up & running In theorie zou alles ineens moeten draaien (wishfull thinking :p). Ik weet niet hoe lang dat gaat duren

Ik moet alleen nog even de CLI fatsoeneren zodat ermee te werken is voor de rest van de wereld. Voor wanne-be-ta-testers graag een PM'etje

Goed bezig JayTaph!

Respect! We owe you one!

*ZuchtSteunPoef*

Mijn checksum werkt ..  Foutje mijn kant achteraf.. maar heeft toch wel heel veel tijd gekost (voor de geinteresseerde: ik laad de file in een buffer en doe MSW/LSW swaps over een aantal variabelen, daarom wordt de checksum verkeerd berekend over die variablen, je oog moet er maar net op vallen :p)

Morgen weinig tijd dus ik denk niet dat ik dan heel veel kan doen.. maar we zijn er bijna heb ik het idee

Het gaat zoiezo al een stuk sneller omdat iemand al een keer heeft uitgezocht hoe de data opbouw is. Dan gaat het inderdaad een stuk makkelijker En zo te horen heb jij inmiddels alles basis functionaliteit al geïmplementeerd. De rest is UI en gebruiksvriendelijke logica, kan iemand anders misschien wel een keer naar kijken.

Raar. Bij de cdj800 kon je wel cuepunten uitwisselen

Geen tijd vandaag om iets (nuttigs) te doen aan de merger   

De CD kant gaat vrij ok voor zover ik kan zien.. minus wat haken en ogen die ik de komende dagen ga aanpassen. Daarna kan dat in ieder geval getest gaan worden :p

De "mp3" kant van het verhaal is wat ingewikkelder. Daarvoor heb ik ook niet alle data beschikbaar. Voor mergen lijkt het (vooralsnog) niet veel uit te maken, aangezien ik alleen maar hoef te identificeren welke blokken in moet mergen. Wat erinstaat is niet zo heel erg van belang.
Bekijken en editten van specifieke data (de cue en looptijden bijvoorbeeld) daarintegen zal dus voorlopig nog niet gaan voor MP3 cd's.

Mooi dat je de checksum werkend hebt. Ik heb eens gekeken wat er bij mij uitkwam bij de checksum, en dat is toch wat anders dan wat die niels had gevonden. Dit is van 4 willekeurige cd's:

43:53:55:4D:20:20:20:2E:F1:20:2E:F7
43:53:55:4D:20:20:20:2E:BD:4E:2E:3D
43:53:55:4D:20:20:20:2E:FB:74:2E:DA
43:53:55:4D:20:20:20:2E:C4:7B:2E:19

Kan dit kloppen of heb ik het verkeerd 'vertaald'?

Ik denk dat er maar weinig mensen zijn die waarde hechten aan het mergen van mp3's, hoewel het wel een leuke bijkomstigheid is natuurlijk. Ik heb zelf welgeteld 4 mp3 cd's waarvan ooit wat op m'n kaartjes is geschreven. Als je ergens draait waar geen mp3-cd-spelers staan heb je er niks aan, dus gebruik ik het niet.

Denk ook dat MP3 discs niet het belangrijkste zijn... De meeste mensen die ik ken draaien toch met audio CD's, mp3 wordt meestal alleen meegenomen als backup.

Poster: Lead
Denk ook dat MP3 discs niet het belangrijkste zijn... De meeste mensen die ik ken draaien toch met audio CD's, mp3 wordt meestal alleen meegenomen als backup.

 
Uhm ik draai bijna alleen maar MP3.. mijn cd's zijn in stijlen opgedeeld. Dus is lekker makkelijk zoeken.

Poster: RAS
Mooi dat je de checksum werkend hebt. Ik heb eens gekeken wat er bij mij uitkwam bij de checksum, en dat is toch wat anders dan wat die niels had gevonden. Dit is van 4 willekeurige cd's:

43:53:55:4D:20:20:20:2E:F1:20:2E:F7
43:53:55:4D:20:20:20:2E:BD:4E:2E:3D
43:53:55:4D:20:20:20:2E:FB:74:2E:DA
43:53:55:4D:20:20:20:2E:C4:7B:2E:19

Kan dit kloppen of heb ik het verkeerd 'vertaald'?

 
Geen idee.. heb de rest van de data nodig om de checksum te genereren. Alles tot aan wat je nu hebt (bestand - laaste 12 bytes zeg maar) moet je optellen en de laatste 32bits is je checksum.
43,54,55,4d is vrij vertaald naar 'CSUM' (dat is je checksum signature), de volgende 4 bytes is je (32bit) veld groote (die niet helemaal klopt bij checksum), daarna volgt je 16 bit feitelijke checksum (F120, BD4E, FB74 en C47B) in jouw geval, en de laatste 16 bits mag je negeren. waar je de 20:20:20:2E vandaan tovert weet ik niet, want dat zou 00:00:00:02 moeten zijn

Ik denk dat er maar weinig mensen zijn die waarde hechten aan het mergen van mp3's, hoewel het wel een leuke bijkomstigheid is natuurlijk. Ik heb zelf welgeteld 4 mp3 cd's waarvan ooit wat op m'n kaartjes is geschreven. Als je ergens draait waar geen mp3-cd-spelers staan heb je er niks aan, dus gebruik ik het niet.

 
Ik doe voorlopig de mp3's ook even achterwege laten qua editten, maar ik wil ze wel fatsoenlijk kunnen mergen. Maar wil het natuurlijk wel erin hebben straks voor de volledigheid :p

We zijn er bijna :p

Ziet er goed uit

Ik heb hier meerdere spelers en kaartjes dus als er te testen is doe ik dit graag...
commandline is niet zo'n probleem

Ik ben em aan het bouwen onder linux, maar het is allemaal vrij standaard C, dus zodra ik klaar ben doe ik em omzetten naar windows (& mac misschien).

Ik ben ondertussen ook een beetje aan het stoeien met de waves. Ik krijg nog niet echt duidelijkheid over hoe dat formaat precies in elkaar steekt. Aanpassingen maken werkt, maar de display op de MK3 doet niet helemaal tonen wat ik wil hebben. Maar dat is latere zorg.

Heb ook even de hele zut moeten omgooien, omdat ik niet happy was met de manier waarop het geheel draaide intern. Dat ziet er dus nu een stuk netter uit (alhoewel er niks veranderd is aan de buitenkant).

Ik ga vandaag wat testen met gemergde kaartjes. Als er mensen zijn die willen testen, graag via PM contact zodat we iets via email of msn kunnen afspreken.

Tijdens een msn-gesprek met JayTaph kwam het volgende ter sprake:

Stel je voor: Je hebt 2 SD-kaartjes en op beide kaartjes heb je soms dezelfde cue-points gemaakt van dezelfde cd's, maar je zit er net één of twee frames naast:
kaartje A: cuepoint cd 54, nr 01, 03:42:53f
kaartje B: cuepoint cd 54, nr 01, 03:42:54f

Je bedoeling is natuurlijk dat dit één en hetzelfde cuepoint is zogauw je deze 2 kaartjes gaat mergen.

Zou je willen dat het programma'tje standaard een range van 2 frames in acht neemt om cue-points van 2 kaartjes als één te zien?

Het uitgebreidere plan is om het progamma'tje standaard een range van 2 frames aan te laten houden, maar je eventueel ook een andere range aan kunt geven. Bijvoorbeeld een range van 0, waarbij dus 2 cue-points op het eindresultaat komen. Wat is jullie gedachte hierover?

@Lead: Waarom kan ik mijn startpost niet meer wijzigen?

JA :D

Je kunt een start post niet wijzigen als een mod hem heeft gewijzigd.

@Is dat niet terug te draaien? Ik zou m'n startpost wat actueler willen maken.

Nog even over de range van 2 frames:
De andere kant van het verhaal is, dat wanneer je zelf bewust 2 cue-points net 2 frames uit elkaar hebt liggen dat je dan een cue-point mist na het mergen. Als dit voor jou geld horen we dat graag . (ik kan het me haast niet voorstellen)

Op dit moment werkt het zo:

je hebt standaard een range (frame-margin) van 2 frames.   Een cue op 5m02s14f is dan gelijk aan 5m02s12f t/m 5m02s16f.

Met de "range" functie kun je de range aanpassen. Zodra je "range 0" ingeeft, dan zal de margin vervallen en zijn dus alle cues verschillend (en dan kun je dus 2 cues heel dicht bij elkaar plaatsen).
Of je kunt ook je range flink verwijden ("range 75" maakt een range van +1 en -1 seconde)..  waarom iemand dat zou willen is me ook een raadsel, maar het kan   Standaard 2 frames margin is voor default wel ok denk ik.

(een loop-cue en een normale cue die dicht bij elkaar liggen mag altijd.. die worden niet op elkaar gecontroleerd aangezien het verschillende types zijn).



Vandaag begonnen met echte testen op de CDJ's.. en zo te zien lukt alles aardig..  Alles wordt netjes gemerged en geindexeerd en is af te spelen op de CDJ's..

De eerste beta-testers kunnen zich snel melden :p

De eerste v0.01b beta release zijn naar de eerste groep testers

Hoera!!
Zoals iedereen kan lezen in de posts hierboven is JayTaph al druk bezig geweest met de realisatie van een MK3 SD Merger. Het verkeerd nu in de beta-status wat betekend dat een aantal mensen het nu aan het testen zijn. Hij heeft hiervoor een nieuw topic geopend waar iedereen nu terrecht kan.

Slotje!!

We gaan verder in: "CDJ1000 MK3 SD merger applicatie"

Poster: RAS
We gaan verder in: "CDJ1000 MK3 SD merger applicatie"

 

Dat was wel de bedoeling ja