Hello! :)

I have a Sony MZ-RH10 - the one with the OLED display at the top, not at the edge. Well, previously I had used a Windows XP VM to use SonicStage to transfer my stuff. But oddly...it stopped working that way. Very, very unfortunately... So I compiled this project on Mac OS (latest Qt and deps installed through Homebrew) and tried to write a MP3 file... Well, here is what happens. Normally I use fish, but to show what bash reports, I switched inbetween.

[email protected] ~/W/G/linux-minidisc $ ./himdcli/himdcli /Volumes/NO\ NAME/ writemp3 /Users/Ingwie/Music/Eigene\ Musik/01\ Kopf\ oder\ Zahl.mp3
fish: './himdcli/himdcli /Volumes/NO\…' terminated by signal SIGABRT (Abort)
[email protected] ~/W/G/linux-minidisc $ bash --login
[email protected] ~/Work/Git/linux-minidisc $  ./himdcli/himdcli /Volumes/NO\ NAME/ writemp3 /Users/Ingwie/Music/Eigene\ Musik/01\ Kopf\ oder\ Zahl.mp3
Abort trap: 6

So... What am I doing wrong?

Kind regards,
Ingwie

The wav files I want to transfer to my MZ-RH1 are visible but are greyed out. I can connect to the device and the files actually on the device are visible. I am not sure if this is a permissions issue. Is there a way of using the terminal to try to send files and get some kind of feedback or error messages? Also my wave files are around 50Mb each so I'm not sure if there is a size limit. What tests can I perform to try to correct this issue? Thanks.

Hello.

Is it possible to split a track (insert TOC mark) by means of netmdcli? Maybe some hex-command could do that?
It would be really helpful when dubbing CDs without silence between tracks or even split tracks from .cue files.

Alex

Downloadhack (transferrring songs FROM the minidisc to the PC) is absolutely necessary in order to have a proper way of archiving minidiscs now the format gets older. Only the MZ-RH1 is capable of doing this in .aea format for ATRAC1. For Atrac 3, Atrac3Plus, Mp3 and PCM there are no solutions yet. You still need Sonicstage for that, which might add DRM.

Porting downloadhack.py to libnetmd is necessary so other developers can tap into it in 3rd party Minidisc software. Also from there it can be extended to work with other formats.

Sweet32 found a vulnerability in 3DES encryption which is used on Hi-MD tracks.
Can it be used on the Hi-MD tracks?

@glaubitz used to work on the key encryption and decryption.

3DES is officially retired in favor of AES.

https://sweet32.info/

https://www.cryptomathic.com/news-events/blog/3des-is-officially-being-retired

There is a minor cosmetic issue with the identifier for the Windows builds in Github Actions.

Despite building the project for 32- and 64-bit Windows, the identifiers in use are ubuntu-latest.

As discussed in #12, right now different ID3 tag libraries are used, and for upload and download and GUI and CLI (and combinations of those), ID3 tags are not always written or read.

To fix this, use taglib for reading and writing tags, and move the reading of tags (when transferring MP3s from PC to Hi-MD) as well as writing of tags (when transferring MP3s from Hi-MD to PC) directly from within libhimd, so that the MP3 writing/reading is consistent between CLI and GUI.

First of all, thanks to everyone involved in making linux-minidisc happen, in this original form and many of the forks!

I've been trying to produce minidiscs from FLAC's using NetMD hardware, and was very happy to get pixelkaisers fork working, with support for SP transfers instead of LP2/LP4. Although it seems to be working great, an audible 'pop' is noticeable on the recording, at about 00:47 intervals. This seems to correspond with the 0x00800000 chunksize that is used by this fork.

However, the original code for netmd_prepare_packets was written in the original linux-minidisc, so I'm hoping to find some help here.

Steps to reproduce:

• Transfer a 44.1kHz 16 bit stereo .wav file using pixelkaiser/linux-minidisc to a minidisc (with netmdcli send)
• Play uploaded file back

If the chunksize is reduced to 0x1000 (4096 bytes), the 'pop' occurs multiple times per second, so it has something to do with the boundary....

I've compared usb traces with SonicStage 4.3, and can see little difference. In the first bulk-transfer packet, the key is set to 0 when SonicStage is transferring the track, but linux-minidisc actually produces a key there. If the key-memcpy is commented out, nothing but noise appears on the downloaded track.

I think alignment might be off. The first packet should have 24 bytes of header information, but the data itself is copied with a 16 byte offset. Is this correct? I adjusted this value to 24 bytes, but it didn't make a difference. Also, the IV doesn't seem to be needed in the header. The track downloads okay (beside the noise) without the IV copied to the header.

from libnetmd/secure.c :

        /* length + key + iv + data */
        if(first_packet)                                     // length, key and iv in first packet only
            packet_size = 8 + 8 + 8 + p->length;
        else
            packet_size = p->length;

        packet = malloc(packet_size);
        buf = packet;

        /* build packet... */
        if(first_packet) {                                   // lenght, key and iv in first packet only
            netmd_copy_quadword_to_buffer(&buf, full_length);
            memcpy(buf, p->key, 8);
            memcpy(buf + 8, p->iv, 8);
            memcpy(buf + 16, p->data, p->length);

Any help is greatly appreciated! I'd love to get this to work!

There are some forks that have moved forward with NetMD support, it'd be great if we could look into reducing the diff to those by merging things that seem to work for more people.

https://github.com/vuori/linux-minidisc
https://github.com/gavinbenda/linux-minidisc

It seems like @gavinbenda's fork is the most up to date (and regularly used/tested by Platinum MD users?) and includes most of the fixes by @vuori and @tharp.

Or maybe everyone has moved on to Platinum MD and the libs it uses anyway, and this is kind of a pointless exercise, I don't know ;)

Hi

Love the project. Thrilled to be playing around with MiniDisc again.

I have had assorted problems that I mostly ascribe to USB hubs/front panel connectors.

On my windows media PC I think I managed one transfer using a front USB and then never again. Rear USB worked flawlessly.
The MacOS (M2 laptop) I haven't gotten to detect the device through USB-C docks. I will try again later with a straight USB-A to USB-C and see if that works better.
SteamOS/SteamDeck could detect it with a hub but had access problems that I could probably solve if I sat down properly with it.
My linux workstation front USB couldn't detect it at all, it usually works OK, plugging in the rear went fine.
Windows gaming PC, front didn't work (works fine for other things), rear worked great.

So I suspect there is something challenging in using NetMD over hubs. Whether that's a library thing, a NetMD protocol thing or just USB in general I can't say. But I didn't find this documented anywhere and it was very consistent for me.

Will try the straight USB-A-to-C converter and see if that solves the Mac and SteamDeck, that'd be strong correlation.

As discovered by asivery working on the WebMD project, MP3 files sampled at a different sample rate than 44.1kHz cause the flag to be set indicating "this MP3 file uses a non-uniform samplerate". This flag is rejected by the RH1, because the sample rate needs to be fixed over the whole song for its playback method to work. The root cause is an (embarassing) coding bug.

im trying to build the project from the source code, as the precompiled binaries does not start (i.e. crashes in the opening process). I fixed some errors caused by missing libraries by installing them with home-brew.
however, there seems to be something else here:

qhimdmainwindow.cpp:292:43: error: use of undeclared identifier 'qVariantFromValue' ui->himd_devices->addItem(device, qVariantFromValue((void *)dev)); ^ 1 error generated. make[1]: *** [qhimdmainwindow.o] Error 1 make: *** [sub-qhimdtransfer-make_first] Error 2

Do you recognize the error or could maybe track it to a further missing dependency?

to reproduce this I

1. clone the code in to a local directory
2. qmake
3. make

Thanks so much!

Hi. Across 3 os variants (linux/mac os x/windows) with any build or download, mine or otherwise, get any mp3s transferred to a HiMD formatted disc to play on so far, 3 different HiMD players.

Extracting is fine. I've burned images to ads, taken mp3s off images, all kinds of combos. there is either something I am missing, not under sanding, or "intrinsic" - Is HiMD support expected to work for writes to MD, or just reads from?

Hi, I'm new to this project so I might be doing something obviously wrong.

When I connect my MD player to my PC, the only way to hunt down its directory is to use lsusb
I found out that the device directory is /dev/bus/usb/001/013 (013 being a file)
It doesn't show up as anything else.

When I try to set it as the device dir I got an error:

Error opening minidisc device (disc image)
Error opening directory "/dev/bus/usb/001/hmdhifi": no such file or directory.

first of all it doesn't let me choose the device file, only the directory before
Second of all, it appends the directory with /hmdhifi.

What am I doing wrong?
I couldn't find any guide on this.

System info:

OS: Archlinux
Program version: 0.9.16
Kernel: 5.14.3-zen1-1-zen
MD player: Sony MZ-N510

I am attempting to build linux-minidisc on an arm64 Mac, and as of Homebrew/homebrew-core#67170, Qt should support a native build on this platform.

That being said, due to the fact that Homebrew on arm64 no longer installs libraries to /usr/local/lib, any installation which isn't using pkg-config correctly will likely fail to find the requisite libraries.

In the case of linux-minidisc, libgcrypt, libgpg-error (a dependency of libgcrypt) and libid3tag appear to not be using pkg-config in this situation, which causes them to fail to be found. I've worked around this by manually passing INCLUDEPATH and LIBS variables to qmake, but this isn't a particularly pleasant solution.

https://github.com/linux-minidisc/linux-minidisc/blob/43a01190f819e44c5709017b889be9bf8766b989/build/libgcrypt.pri

https://github.com/linux-minidisc/linux-minidisc/blob/43a01190f819e44c5709017b889be9bf8766b989/build/libid3tag.pri

# ./lsmd.py 
Traceback (most recent call last):
  File "./lsmd.py", line 82, in <module>
    show_uuids=options.uuids)
  File "./lsmd.py", line 9, in main
    listMD(md, show_uuids)
  File "./lsmd.py", line 40, in listMD
    flags = reprDiscFlags(md_iface.getDiscFlags())
  File "/home/me/linux-minidisc/netmd/libnetmd.py", line 631, in getDiscFlags
    return self.scanQuery(reply, '1806 01101000 1000 0001000b %b')[0]
  File "/home/me/linux-minidisc/netmd/libnetmd.py", line 442, in scanQuery
    format_value, input_value))
ValueError: Format and input mismatch at 6: expected 10, got ff

Running on Debian 9.

I've been trying to get netmd track download to work, but had some troubles and doubts. First of all, why is LP2 wireformat default? There is no way to encode atrac in Linux, mp3, ogg and flac are more common and easily re-encoded to raw pcm wireformat. I've been working this way with the python version for a long time.

I've found a pair of bugs in secure.c (or that seems to me).

Line 394: size_t chunksize = 0xffffffffU;

Should be chunk size 4Gb? libusb_bulk_transfer fails when trying to send the whole track in one single packet (~48Mb). Smaller values work for me, but not sure how to determine the best value.

Line 384: There is a lonely break which only allows to one packet to be sent. I guess a "else" scope is missing.

Fixing both lines sent the whole track down to the MD, but after that, it fails polling for a response (Still guessing why :S ) and the sync toc and so one seems to have no effect, device gets stuck "accessing" forever.

Tested on Ubuntu 16.04 x86_64

Is there a way to get accurate track lengths on the MiniDisc? Values reported by netmd_track_get_length are not precisely correct. I have transferred several MDs to PC using analog connection and confirmed that with 2 different NetMD devices. I have also tried a bit of cheating by sending netmd_start_playback command and reading netmd_get_playback_position in a tight loop, but it did not work as expected as it looks like responses are cashed. In other words, I cannot detect when one track changes to another accurately. For example:

0: 00:00:00+004
0: 00:00:00+004
0: 00:00:00+004
0: 00:00:00+004
0: 00:00:00+004
0: 00:00:00+004
0: 00:00:00+004
...
0: 00:00:00+004
0: 00:00:00+028
0: 00:00:00+028
...
0: 00:00:00+028
0: 00:00:00+048
0: 00:00:00+048
...
0: 00:00:00+048
0: 00:00:00+072
0: 00:00:00+072
...
0: 00:00:00+072
0: 00:00:01+005
0: 00:00:01+005
...
0: 00:00:01+005
0: 00:00:01+029
0: 00:00:01+029
...
0: 00:00:01+029
0: 00:00:01+049
0: 00:00:01+049

I'm rather new to the NetMD world and recently acquired a used Sharp IM-DR420H device. Unfortunately, I keep getting "Unknown Error" messages when sending a file:

netmdcli send file.wav
Net MD
Raw title:  
Disc Title: <Untitled>

Unknown Error
Unknown Error
Unknown Error
Unknown Error
Unknown Error
Unknown Error
No error
Unknown Error
Unknown Error
Unknown Error
Unknown Error

Running with -t, I get (only the first few lines):

Net MD
Raw title:  
Disc Title: <Untitled>

Command:
00 18 00 08 00 46 f0 03 01 03 81 ff             		.....F�...��
Response:
0a 18 00 08 00 46 f0 03 01 03 81 ff             		.....F�...��
Unknown Error
Command:
00 18 00 08 00 46 f0 03 01 03 2b ff 00 01 00 00 		.....F�...+�....
01                                              		.
Response:
08 18 00 08 00 46 f0 03 01 03 2b ff 00 01 00 00 		.....F�...+�....
01                                              		.
Unknown Error
Command:
00 18 00 08 00 46 f0 03 01 03 80 ff             		.....F�...��
Response:
0a 18 00 08 00 46 f0 03 01 03 80 ff             		.....F�...��
Unknown Error

Any help is appreciated!

I'm on a recent Arch Linux system, I also tried @vuori's fork and platinum-md with the same result. Controlling the device (netmdcli play) works, reading disc information also works.

netmdcli play track bug

there is a bug on netmdcli play #track, probably affects other commands that use strtoul function too. Whenever you select a track number, it interpretes it as a hex number rather than decimal.

Hi!

The recently introduced wavefilewriter breaks the build on the s390x, ppc64 and sparc64 architectures in Debian [1, 2, 3]:

g++ -m64 -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -o qhimdtransfer main.o qhimdaboutdialog.o qhimdformatdialog.o qhimduploaddialog.o qhimdmainwindow.o qhimddetection.o qmdmodel.o qmdtrack.o qmddevice.o qhimddummydetection.o wavefilewriter.o moc_qhimdaboutdialog.o moc_qhimdformatdialog.o moc_qhimduploaddialog.o moc_qhimdmainwindow.o moc_qhimddetection.o moc_qmdmodel.o moc_qmddevice.o qrc_icons.o -L../libhimd -L../libnetmd -L/usr/lib/sparc64-linux-gnu -L../libhimd -lhimd -lmad -L../libnetmd -lnetmd -lgcrypt -lglib-2.0 -lusb-1.0 -ltag -lQtGui -lQtCore -lpthread
wavefilewriter.o: In function unsigned long qToLittleEndian<unsigned long>(unsigned long)': /usr/include/qt4/QtCore/qendian.h:342: undefined reference to unsigned long qbswap(unsigned long)'
collect2: error: ld returned 1 exit status

It seems a very similar issue was fixed in goldendict [4].

This is something we have to fix as otherwise linux-minidisc will not be shipped in Debian Stretch!

Adrian

[1] https://buildd.debian.org/status/fetch.php?pkg=linux-minidisc&arch=s390x&ver=0.9.14-1&stamp=1481283541
[2] https://buildd.debian.org/status/fetch.php?pkg=linux-minidisc&arch=ppc64&ver=0.9.14-1&stamp=1481285857
[3] https://buildd.debian.org/status/fetch.php?pkg=linux-minidisc&arch=sparc64&ver=0.9.14-1&stamp=1481283862
[4] LocutusOfBorg/goldendict@c035954

There is no recent Windows build. There is no Travis build bot for it.
Can you please fix this?

https://travis-ci.org/github/glaubitz/linux-minidisc

Back in the day I recorded loads of concerts using a Sony MiniDisc. I then used the software sonicstage to copy the openmg atrac audio files *.omg from the minidisc to my PC to archive them on a hard disk.
What I did not know: The files were protected with DRM and the key was stored in a file which I did not backup.
Since years I am looking for a way to unlock/crack those files (which are my own recordings of my music).
I would be so thankful and also ready to pay, if anyone knows a solution or a pointer to a solution.

hello,
after successfully compile on Fedora 32, connecting reports the above error.
Error opening minidisc device (SONY MZ-N910 (NetMD)):
Error opening netmd: Error while opening the USB device

Any ideas?
Is it possible to create logs?

Regards
Poul

Platform: Linux, Pop!_OS 21.10

Looks similar to #68

Cloned repo and build from source. netmdcli and qhimdtransfer both compiled successfully.
Added my user to plugdev group, and installed the udev rule.

netmdcli reports:
"Error opening netmd
Error while opening the USB device"

qhimdtransfer reports:
"Error opening minidisc device (SONY MZ-NE410 / MZ-DN430 / MZ-NF520 (NetMD)):
Error opening netmd: Error while opening the USB device.

Hello everyone.

According to my question in netmd-js project which asivery gave me very useful answers.
However, we still don't know why a MD device requires a 16bit/44.1khz input file for recording in SP mode?

I would be glad if you could show me where to get this 16bit/44.1khz SP mode specification or how do you reverse engineer to get this input file's requirement.

Thank you.

Hi,
I want install linux-minidisc, but a recieve this error :
"
lio@Karkatouf:~/linux-minidisc$ qmake -r
qmake: could not find a Qt installation of ''
"
I'm on ubuntu 13.10 AMD64. I Want install the logiciel from the git because with the deb from synaptic, the program run, can see my HIMD (not the NetMD), he can see the music on the HI-MD, but when I clic on "transfer", it nothing happens. I haven't answer from the terminal. :'( :'( :'(

With a Sony MD Walkman MZ-NH600

I've an MZ-NH600D, and am using basictools compiled from source on Ubuntu 19.10 on x86_64. himdformat fails with a 1GB disc:

$ sudo ./himdformat /dev/sg2 
Formatting failed! Sense data: 70 00 03 00 00 00 00 0A 00 00 00 00 30 00 00 00 

But himdscsitest /dev/sg2 format succeeds:

$ sudo ./himdscsitest /dev/sg2 format
scsidev: '/dev/sg2'
devname: '/dev/sg2'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.36
Please wait, formatting device.
HiMD successfully formatted.

An 80min MiniDisc formatted as Hi-MD is formatted by both tools.

If building linux minidisc without gui, via qmake CONFIG+=without_gui, package_build.sh fails due to missing QHiMDTransfer.exe.

So first, I tried this:

[email protected] ~/W/G/linux-minidisc $ ./netmdcli/netmdcli send /Applications/Ygopro/sound/deck.mp3 
Net MD Walkman
Raw title: test 
Disc Title: test

No error
No error
No error
No error
No error
No error
No error
netmd_exch_message: netmd_poll failed
Unknown Error
netmd_exch_message: netmd_poll failed
Unknown Error
No error
No error

Then I unplugged the device and scoped through the songs, and only found three songs... Well, turns out that is what the program reports - as well as a crash?

[email protected] ~/W/G/linux-minidisc $ ./netmdcli/netmdcli 
Net MD Walkman
Raw title: test 
Disc Title: test

Track  0: TrPROT    LP4 - 01:40:02 - Intro
Track  1: TrPROT    LP4 - 04:12:30 - Algemeine Musik - Raucherlied
Track  2: TrPROT    LP4 - 03:51:31 - Dirk Krempel - Kakalakenlidchen2

--Empty Groups--


fish: './netmdcli/netmdcli' terminated by signal SIGABRT (Abort)

Running LLDB over it:

[email protected] ~/W/G/linux-minidisc $ lldb ./netmdcli/netmdcli
(lldb) target create "./netmdcli/netmdcli"
Current executable set to './netmdcli/netmdcli' (x86_64).
(lldb) run
Process 31503 launched: './netmdcli/netmdcli' (x86_64)
Net MD Walkman
Raw title: test 
Disc Title: test

Track  0: TrPROT    LP4 - 01:40:02 - Intro
Track  1: TrPROT    LP4 - 04:12:30 - Algemeine Musik - Raucherlied
Track  2: TrPROT    LP4 - 03:51:31 - Dirk Krempel - Kakalakenlidchen2

--Empty Groups--


Process 31503 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x00007fff7c09523e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
->  0x7fff7c09523e <+10>: jae    0x7fff7c095248            ; <+20>
    0x7fff7c095240 <+12>: movq   %rax, %rdi
    0x7fff7c095243 <+15>: jmp    0x7fff7c08f3b7            ; cerror_nocancel
    0x7fff7c095248 <+20>: retq   
Target 0: (netmdcli) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff7c09523e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007fff7c14bc1c libsystem_pthread.dylib`pthread_kill + 285
    frame #2: 0x00007fff7bffe268 libsystem_c.dylib`__abort + 144
    frame #3: 0x00007fff7bffeaf6 libsystem_c.dylib`__stack_chk_fail + 205
    frame #4: 0x000000010000321c netmdcli`print_disc_info + 684
    frame #5: 0x0000000100001dbb netmdcli`main + 1099
    frame #6: 0x00007fff7bf55ed9 libdyld.dylib`start + 1

This is basically just my spare player. But it'd be nice to use it, too :)