The lang by default is just "C". I'm sure your Ubuntu is probably UTF-8
You can try to change your locale on pCP. Install getlocale.tcz. Then run getlocal.sh.
Results 21 to 30 of 44
Thread: MP3 tag manipulation under pCP
-
2020-04-17, 10:35 #21piCorePlayer a small player for the Raspberry Pi in RAM.
Homepage: https://www.picoreplayer.org
Please donate if you like the piCorePlayer
-
2020-04-17, 13:53 #22
Thanks Paul - that seems to have done the trick.
The pCP locale was indeed set to "C", and my Ubuntu Macbook was set to "en_GB.UTF-8". So I installed getlocale.tcz, used the /usr/local/bin/getlocale.sh utility to add "en_GB.UTF-8" to pCP, added "lang=en_GB.UTF-8" to cmdline.txt, and did a pcp br. I then retried my lame tests, and it seems like the tags are being properly written to the file now.
@Ralphy - is that the difference with your pCP setup? Have you also changed the locale from "C" to something else?
-
2020-04-18, 02:46 #23
It turns out that the missing id3v2 tags can be written in latin1 (1 byte) characters when the locale is set to 'C', just by using the --id3v2-latin1 switch. I thought I'd already tried that, but I suspect I may have missed off the '1' at the end of the switch.
The other character encoding switch, --id3v2-utf16, doesn't do anything when the locale is "C"
I don't know enough about character encoding to sound knowledgable here, but it seems the only way to get UTF16 characters into the id3v2 tag fields (which I believe is the preferred format for id3v2), is to set the locale to a UTF-8 variant.
-
2020-04-18, 03:19 #24
That's not right. LATIN-1 is allowed.
Originally Posted by wikipedia
-
2020-04-18, 05:28 #25Ralphy
1-Touch, 5-Classics, 3-Booms, 2-UE Radio
Squeezebox client builds donations always appreciated.
-
2020-04-18, 05:37 #26
-
2020-04-18, 06:20 #27
So just by way of a baseline, I started again from scratch. Another new pCP6.0.0 image in a different Raspberry Pi4 - only this time I've used wired internet, rather than wireless, to eliminate any possibility that editing the wpa_supplicant file, or even mounting the boot partition in a GB-based Macbook, could be making a difference. So the SD card came straight out of the laptop after writing the image (i.e. it was never mounted), and straight into the RPi4.
I booted it up, loaded pcp-lame.tcz and pcp-id3v2.tcz via the web interface, transferred a small wav file via Filezilla (the 'testcase.wav' file that comes with the lame source code), and then encoded it with lame as follows. The hexdump and id3v2 utility both show that the TPE1 tag is empty.
Code:tc@piCorePlayer:~$ lame --id3v2-only --ta lameartist testcase.wav testcase.mp3 LAME 3.100 32bits (http://lame.sf.net) Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz Encoding testcase.wav to testcase.mp3 Encoding as 44.1 kHz j-stereo MPEG-1 Layer III (11x) 128 kbps qval=3 Frame | CPU time/estim | REAL time/estim | play/CPU | ETA 23/23 (100%)| 0:00/ 0:00| 0:00/ 0:00| 5.5488x| 0:00 ------------------------------------------------------------------------------- kbps LR MS % long switch short % 128.0 95.7 4.3 78.3 13.0 8.7 Writing LAME Tag...done ReplayGain: -1.6dB tc@piCorePlayer:~$ hexdump -C -n 256 testcase.mp3 00000000 49 44 33 03 00 00 00 00 00 54 54 53 53 45 00 00 |ID3......TTSSE..| 00000010 00 2f 00 00 00 4c 41 4d 45 20 33 32 62 69 74 73 |./...LAME 32bits| 00000020 20 76 65 72 73 69 6f 6e 20 33 2e 31 30 30 20 28 | version 3.100 (| 00000030 68 74 74 70 3a 2f 2f 6c 61 6d 65 2e 73 66 2e 6e |http://lame.sf.n| 00000040 65 74 29 54 50 45 31 00 00 00 03 00 00 01 ff fe |et)TPE1.........| 00000050 54 4c 45 4e 00 00 00 04 00 00 00 35 36 36 ff fb |TLEN.......566..| 00000060 90 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.D..............| 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000080 00 00 49 6e 66 6f 00 00 00 0f 00 00 00 17 00 00 |..Info..........| 00000090 27 2e 00 0b 0b 0b 0b 16 16 16 16 21 21 21 21 21 |'..........!!!!!| 000000a0 2c 2c 2c 2c 37 37 37 37 42 42 42 42 42 4d 4d 4d |,,,,7777BBBBBMMM| 000000b0 4d 59 59 59 59 64 64 64 64 64 6f 6f 6f 6f 7a 7a |MYYYYdddddoooozz| 000000c0 7a 7a 85 85 85 85 85 90 90 90 90 9b 9b 9b 9b a6 |zz..............| 000000d0 a6 a6 a6 a6 b2 b2 b2 b2 bd bd bd bd c8 c8 c8 c8 |................| 000000e0 c8 d3 d3 d3 d3 de de de de e9 e9 e9 e9 e9 f4 f4 |................| 000000f0 f4 f4 ff ff ff ff 00 00 00 39 4c 41 4d 45 33 2e |.........9LAME3.| 00000100 tc@piCorePlayer:~$ id3v2 -l testcase.mp3 id3v2 tag info for testcase.mp3: TSSE (Software/Hardware and settings used for encoding): LAME 32bits version 3.100 (http://lame.sf.net) TPE1 (Lead performer(s)/Soloist(s)): TLEN (Length): 566 testcase.mp3: No ID3v1 tag
Code:tc@piCorePlayer:~$ locale LANG=C LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_PAPER="C" LC_NAME="C" LC_ADDRESS="C" LC_TELEPHONE="C" LC_MEASUREMENT="C" LC_IDENTIFICATION="C" LC_ALL=
- Regional differences in the embedded firmware?
- Connecting to a GB-based router?
- Accessing via Filezilla from a GB-based Macbook?
- Accessing via ssh from a GB-based Macbook?
Is anyone else able to repeat my steps above to see if they get the same result?
-
2020-04-18, 14:14 #28
hi chill,
This stuff is beyond me but I did notice in your original example, one was 32bit and the other 64bit. Don't know if that is relevant,
-
2020-04-18, 16:20 #29
Yes, that's true. The version on my Macbook is 64 bit, which I think might account for some of the speed advantage compared to the RPi4. The version in the pCP repository is 32 bit, so I expect that Ralphy is using the same 32 bit version as me.
I'm puzzled that Ralphy sees a different behaviour from me. If my 'plain vanilla' pCP version wrote v2 tags correctly and Ralphy's didn't, I'd put that down to something odd in Ralphy's installation (some additional settings or software), but this is a standard lame feature that doesn't seem to work on my basic 'clean out of the box' install, whereas it does on Ralphy's. I'm at a loss to understand what could be different.
-
2020-04-19, 01:17 #30
Another day, another crack at this. And I've made progress. It turns out that all I need to do to get v2 tags working in lame is to load the getlocale.tcz extension. I don't even need to run the script to set the locale with it - I just need to use the pCP extensions interface to load it.
My locale stays as "C", and if I then run lame with the --id3v2-only option I get a 2-byte (UTF-16?) v2 tag in the output.
So does this suggest a missing dependency in lame? Something that happens when getlocale.tcz is loaded is enough to fix it:
Code:Downloading: bash.tcz bash.tcz: OK Downloading: glibc_apps.tcz glibc_apps.tcz: OK Downloading: glibc_i18n_locale.tcz glibc_i18n_locale.tcz: OK Downloading: glibc_gconv.tcz glibc_gconv.tcz: OK Downloading: getlocale.tcz getlocale.tcz: OK
- Burn the image
- Boot the wired RPi4 from this image
- Load pcp-lame.tcz
- Copy testcase.wav to /home/tc
- $ lame --id3v2-only --ta lameartist testcase.wav <- tag NOT written to testcase.mp3
- Load getlocale.tcz
- $ lame --id3v2-only --ta lameartist testcase.wav <- v2 tag successfully written testcase.mp3
Code:tc@piCorePlayer:~$ hexdump -C -n 256 testcase.mp3 00000000 49 44 33 03 00 00 00 00 00 68 54 53 53 45 00 00 |ID3......hTSSE..| 00000010 00 2f 00 00 00 4c 41 4d 45 20 33 32 62 69 74 73 |./...LAME 32bits| 00000020 20 76 65 72 73 69 6f 6e 20 33 2e 31 30 30 20 28 | version 3.100 (| 00000030 68 74 74 70 3a 2f 2f 6c 61 6d 65 2e 73 66 2e 6e |http://lame.sf.n| 00000040 65 74 29 54 50 45 31 00 00 00 17 00 00 01 ff fe |et)TPE1.........| 00000050 6c 00 61 00 6d 00 65 00 61 00 72 00 74 00 69 00 |l.a.m.e.a.r.t.i.| 00000060 73 00 74 00 54 4c 45 4e 00 00 00 04 00 00 00 35 |s.t.TLEN.......5| 00000070 36 36 ff fb 90 44 00 00 00 00 00 00 00 00 00 00 |66...D..........| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000090 00 00 00 00 00 00 49 6e 66 6f 00 00 00 0f 00 00 |......Info......| 000000a0 00 17 00 00 27 2e 00 0b 0b 0b 0b 16 16 16 16 21 |....'..........!| 000000b0 21 21 21 21 2c 2c 2c 2c 37 37 37 37 42 42 42 42 |!!!!,,,,7777BBBB| 000000c0 42 4d 4d 4d 4d 59 59 59 59 64 64 64 64 64 6f 6f |BMMMMYYYYdddddoo| 000000d0 6f 6f 7a 7a 7a 7a 85 85 85 85 85 90 90 90 90 9b |oozzzz..........| 000000e0 9b 9b 9b a6 a6 a6 a6 a6 b2 b2 b2 b2 bd bd bd bd |................| 000000f0 c8 c8 c8 c8 c8 d3 d3 d3 d3 de de de de e9 e9 e9 |................|